A Methodology for Developing and Deploying Intranet and Internet Solutions

Overview

A Methodology for Developing and Deploying Internet and Intranet Solutions.

World-class techniques for managing today's business-critical IT projects.

Today's intranet, Internet, and client/server deployments involve more sites, more participants, more technologies, and more complexity than ever before. Now, top Hewlett-Packard project manager Jeff Greenberg introduces a complete reusable methodology for ...

See more details below
Available through our Marketplace sellers.
Other sellers (Hardcover)
  • All (9) from $1.99   
  • New (4) from $1.99   
  • Used (5) from $2.39   
Close
Sort by
Page 1 of 1
Showing All
Note: Marketplace items are not eligible for any BN.com coupons and promotions
$1.99
Seller since 2005

Feedback rating:

(179)

Condition:

New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.

New
1997-12-05 Hardcover New New Condition. Hardcover.

Ships from: Gilroy, CA

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
$38.43
Seller since 2015

Feedback rating:

(0)

Condition: New
"New, Excellent customer service. Satisfaction guaranteed!! "

Ships from: Irving, TX

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
$38.56
Seller since 2015

Feedback rating:

(345)

Condition: New
Brand New Item.

Ships from: Chatham, NJ

Usually ships in 1-2 business days

  • Canadian
  • International
  • Standard, 48 States
  • Standard (AK, HI)
  • Express, 48 States
  • Express (AK, HI)
$45.00
Seller since 2015

Feedback rating:

(217)

Condition: New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Page 1 of 1
Showing All
Close
Sort by
Sending request ...

Overview

A Methodology for Developing and Deploying Internet and Intranet Solutions.

World-class techniques for managing today's business-critical IT projects.

Today's intranet, Internet, and client/server deployments involve more sites, more participants, more technologies, and more complexity than ever before. Now, top Hewlett-Packard project manager Jeff Greenberg introduces a complete reusable methodology for successfully integrating and deploying practically ANY new technology while using Internet and intranet technology as an example.

Through detailed, practical case studies, you'll learn these and other crucial planning skills:

  • Identifying the expertise you'll need.
  • Organizing the project team.
  • Asking critical up-front questions that are usually ignored until it's too late.
  • Developing initial proposals and timelines that minimize risk.
  • Pre-staging the technology solution to assure deployment success.
  • Making sure that your infrastructure is sufficiently robust.
  • Uncovering political and organizational obstacles--and responding to them.

Greenberg introduces "proof-of-concept" prototyping techniques that deliver maximum information for decision-making. He also demonstrates new techniques for high availability by considering infrastructure requirements like architecture, networking, backup, and recovery early on.

Walk step-by-step through the logistics of staging and proliferating new hardware and software. Understand preparing sterile systems and staging tapes, establishing a command center, transferring data, educating users, managing support handoffs, holding useful project postmortems, and much more.

This book delivers the nitty-gritty expertise, tools and forms you need to do an outstanding job of deploying client/server, intranet or Internet technology. Don't manage or sponsor a project without it!

Read More Show Less

Editorial Reviews

Booknews
Discusses the issues involved with planning and managing the implementation of new client-server and Internet technologies. Topics include infrastructure development; implementation pitfalls; support for implementation; advance project management; and criteria for designing a prototype, pilot, and test plan. The approach emphasizes the authors' creation of a case study of a hypothetical business that develops client-server, Internet, and intranet technologies. Annotation c. by Book News, Inc., Portland, Or.
Read More Show Less

Product Details

  • ISBN-13: 9780132096775
  • Publisher: Prentice Hall Professional Technical Reference
  • Publication date: 12/1/1997
  • Series: Hewlett-Packard Professional Bks.
  • Edition number: 1
  • Pages: 320
  • Product dimensions: 6.30 (w) x 9.31 (h) x 1.14 (d)

Read an Excerpt

Preface

"Since we happen to be at the beginning, let's begin here." -J.R. Lakeland
There is an interesting phenomenon today in the computing industry ( I mean other than Bill Gates). There has actually been a small rumbling of what could be considered a ground swell to reverse a technology paradigm shift! I've been in computers for twenty years, and I don't recall this happening before. But I'm way out ahead here so let me back up a decade or two.
The late 1980's saw a new paradigm being introduced. The old paradigm was the monolithic computer, and the associated functional but deadly boring terminal screen. The shift was to client-server computing: the use of one computer or class of computers to act as a computing, data, or application server while another computer or class of computers provide client services. An example many people will be familiar with is the typical on-line service where the screen and editing are being provided by your desktop PC, but the look-up data is maintained on the server end. The two applications speak to each other transparent to the user, as opposed to filling in a screen, pressing enter, and waiting (although even that can be client-server in a very loose model).
Client-server computing is meant to put the processing power where it is needed, thus reducing the need for humongous mainframes and allowing the provision of meaningful information to the user like never before. Sounds great, no? Many CIO's believe so, and showed it by `betting the farm' on client-server technology.
This "ground swell" movement is suggesting that a move back to the mainframe might be appropriate. Why? If client-server technology is so wonderful, why move back to the mainframe? Why even consider shifting the paradigm back with the cost of losing what the shift was supposed to provide, let alone the cost of the reversal? Why do cubicles have signs like:

Mainframes: We're back, and boy are we ticked off! Aside from the fact that the local mainframe sales representative probably photocopied a stack of them and left them around, what would lead to the display of these signs? There is a perception that the client-server paradigm isn't working. I agree to some extent, but not for any reason that would have me advocate people returning to mainframes, the `art' of 80-column JCL, and data in the form of reams of green-bar paper instead of information.
Let's not lose sight of the Internet earthquake, and the aftershock of Intranets. Lest we forget, both are examples of client-server technology, and there's not a darned thing wrong with it. There are ongoing issues with the application side of client-server technology, but before I discuss the cause and solutions, let me expand on the symptoms of the issue.
Symptoms

  • the technology is expensive to manage
  • the applications are expensive to develop
  • payback is lacking Frankly, these symptoms were common long before client-server technology. The inference is that client-server technology itself is the cause of these symptoms. Untrue. The cause is often that much of the planning and implementation to insert client-server technology into these mainframe environments was done by people who had as much idea about implementing it as does my Clumber spaniel, Bumble (and when you look deep into his eyes ya don't see much client-server knowledge), and sometimes that those responsible for its implementation had considerable motivation (they felt) to not have a successful implementation.
    The truly amazing, and often humorous, slant to all of this is that the client-server naysayers seem oblivious not only to the fact that client-server technology is enjoying an enormous success, but that often this success is happening right in their `living room.' They look at the PC with the order-processing application connected to a server and say that it should move back to the mainframe, but all around their company people are using the Internet, and possibly an intranet, and the fact is folks that the whole technology of web pages on a World-Wide Web, in the case of the Internet, or on an intra-company server, in the case of an intranet, is client-server technology! I think that needs to be stated again:
    The Internet and intranets are the successful embodiment of client-server technology! There, the secret is out. Yet nobody is screaming about the Internet not working. No one is saying that intranets are a waste of time. Just the opposite is happening -- Internet Service Provider (ISP) stocks are increasing steadily and anything having to do with the Internet from add-on applications to magazines seem to be a gold mine. Is it simply because the technology is so new that no one understands it yet? Nope. So why are the client-server applications getting bad press? Let's go back to looking through the eyes of Bumble the Wonder Dog. What happens when you launch into anything major in life with the combination of insufficient information and little experience? Consider that combination coming to bear in constructing a house or starting a business: would you want to live in it or work for it?
    Let's take a look at why these problems are really arising.
    1. Politics and empire. Don't underestimate it. He who held the mainframe held the power. In many cases the power base of a distributed computer system, as is the case with client-server, is unclear. So there are instances where the `emperor' is concerned with diluting the powerbase and so, despite giving the go-ahead on a client-server project due to politics there is no desire for that environment to succeed. In other cases, political opponents of a well-meaning CIO (Chief Information Officer) see the large-scale implementation of new technology as opportunity for a covert toppling of the existing powerbase.
    2. CIO's are being misled, intentionally or unintentionally, about the return on investment of client-server technology. The fact is that the technology and development using it have a front-end loaded cost. Implementing an environment of new technology is always costly, as is the learning curve and configuring of the development environment. New equipment has to be purchased; new infrastructure developed or the current infrastructure heavily modified; libraries, databases and objects need to be designed before anything is rolled out let alone a return realized. Therefore, the ROI (return on investment) is weighted towards the back-end on a timeline.
    3. People are losing sight of the biggest ROI ( eliminating the huge mainframe dinosaur. The intention, when the environment is agreed to, is usually to develop a migration plan to get off the dinosaur. What happens very often though is that an inordinate amount of time ends up being spent on GUI's (graphical user interfaces) for applications because they're visual, have immediate impact, and feeds our apparently inherent need for creeping elegance. So the user ends up with just an e-mail system with an above-average paint job, though the billing and purchasing systems are still on the mainframe, thus leaving the mainframe expense intact.
    4. Infrastructure. Hardly anyone is giving it the proper consideration. You might be able to force a round peg into a square hole, but then both the hole and the peg become fairly useless. The thought very often is "the mainframe infrastructure has existed for years -- let's use it." Well, you may not be able to bend and shape it enough without major changes -- even a Slinky® has limits to its adaptability.
    5. Deployment. There are many approaches to deployment, especially when those deploying are unfamiliar with the technology. Often brute force is used. It works, but not well, and can result in positioning the landscape of a very different ROI model without anyone realizing it.
    Given these points of potential failure, I should now provide my rationale in developing this book, and first, why I felt what I have to say is worth reading.
    I began managing enterprise-wide rollouts fifteen years ago. I didn't make a conscious decision to enter this arena; I was a software developer and stumbled into it. At that time the new paradigm was mini-computers used for financial, order processing, manufacturing, and so on. Having designed a research and manufacturing application for a chemical coatings company, I found myself responsible for implementing the technology and applications at multiple sites. Many of the issues in that rollout arose in every subsequent one, albeit with different faces and packaging, and had nothing to do with the application itself, but instead the infrastructure necessary to support it. Through the many implementations I have planned and managed since then, with magnitudes ranging from a handful of systems to upwards of a thousand, and clients including telecom corporations, two of the largest retailers, and a major media corporation, I've developed what has been for me a sanity-saving approach.
    It's the approach I want to pass on to you, and a case study and specific technology example is the method I'll be using. Back in my college days my roommate and I made the not-so-bright decision to drive from our school in Connecticut to his friend's school in New Hampshire, during a frigid New England winter, in a car without a working heater. I remember us slip-sliding along what looked like a small highway on the map, but in reality translated to a path through the mountains. We stopped at a roadside general store and I asked an old gentleman for directions (yes, honey, I actually did that once). He responded with the classic, "Ayuh, ya can't get there from here." Well, looking around at your environment, and then looking at an environment where client-server applications are being used to their potential, including the use of an intranet, might leave you feeling that you can't get there from here, but you can, and I'm going to try to give you directions. I'll also try to provide a map of the pitfalls along the way. At times it might sound very negative, but that's only because all the pitfalls need to be mentioned, even though you might not experience them, while the good stuff that will hopefully happen to you along the way is left to your imagination.
    The bottom line: plan for the planning. Because most of the issues facing an enterprise-wide rollout are repetitive, there exists the ability to plan for their identification before ever walking into the conference room for your first team meeting. Having a clear approach that you're comfortable with will enable you to start off with confidence ( the mark of a leader.
    There's another story about a New England codger, this one in Maine. It seems that a couple from New Hampshire were thinking of moving to Maine (they were probably tired of "not being able to get there from here.") They knew that in most small towns in New England, if you weren't born there you were considered to be "from away," even after twenty-five years of residency. The mother was expecting, and was determined not to have her child grow up being "from away." So when she went into labor, she had her husband drive her to the town in Maine and gave birth there. Later, after having moved and settled in, she was recounting the story to someone in the local general store. An old codger rocking in his chair outside the screen door overheard the story, and when the mother finished the story by expressing that since her son was born there he was a local, the man piped up with, "Ayuh, but a cat crawling into the oven to have her kittens doesn't make them muffins."
    Replacing a successful, existing application with a well-written client-server application doesn't necessarily mean the new application will be successful, but after reading this book, my hopes are that you'll understand what ghosties and ghoulies stand in your way, and what it will take to be successful. And that the understanding of how to be successful will help you to move on to navigating through the fear, uncertainty, and doubt to determine what applications and approach have a chance at being successful after being implemented. Plan well; don't stumble when the paradigm shifts.


    I hope you enjoy reading A Methodology for Developing and Deploying Internet and Intranet Solutions.
    Jeff R. Greenberg Manager, Telecom Solutions Support Program HP Professional Services Organization Atlanta, Georgia May, 1996
Read More Show Less

Table of Contents

Introduction.
1. The Project Manager. The Client. Initial Concerns. Project Charter and Requirements.
2. The Work Breakdown Structure. The Draft Solution. Draft Implementation Vision. Draft Time Line. Assessing Risk. Scope. Assumptions. Pricing. Review. Delivering the Proposal. The Contract.
3. The Internal Kickoff. The Project Team Interviews. Setting up Shop. Client KickOff.
4. The Approach Document. Launching the software development cycle. Implementation scoping. Phase 2 Project Plan.
5. High-Level Design. Proof of Concept. Low-Level Design. Preconstruction. Construction. Internal Testing.
6. Proliferation planning. Site Readiness Checklist. Data Transfer. User Education. Software Releases.
7. Networking. Site Wiring. Backup and Recovery. High Availability. Operations. The Internet.
8. Application Unit Testing. System Testing. System Alpha and Beta Testing. User Acceptance Testing. Phase 3 Proposal.
9. Staging. Scoping the Staging.
10. Pilots. Change Management. Gold Master.
11. The Command center. Support desk start-up. Switch-over. Performance Tuning.
Epilogue.
Appendix A - Technical Stuff.
Client-Server Overview. Client-Server Services. Client-Server Functionality. The Session. The Presentation. The Application Layer. TCP/IP. The Client-Server Application. The Internet.
Appendix B - Project Management.
Work Breakdown Structure. Network Diagram. Gantt Chart.
Glossary.
Index.
Read More Show Less

Preface

Preface: Preface

"Since we happen to be at the beginning, let's begin here." -J.R. Lakeland
There is an interesting phenomenon today in the computing industry ( I mean other than Bill Gates). There has actually been a small rumbling of what could be considered a ground swell to reverse a technology paradigm shift! I've been in computers for twenty years, and I don't recall this happening before. But I'm way out ahead here so let me back up a decade or two.
The late 1980's saw a new paradigm being introduced. The old paradigm was the monolithic computer, and the associated functional but deadly boring terminal screen. The shift was to client-server computing: the use of one computer or class of computers to act as a computing, data, or application server while another computer or class of computers provide client services. An example many people will be familiar with is the typical on-line service where the screen and editing are being provided by your desktop PC, but the look-up data is maintained on the server end. The two applications speak to each other transparent to the user, as opposed to filling in a screen, pressing enter, and waiting (although even that can be client-server in a very loose model).
Client-server computing is meant to put the processing power where it is needed, thus reducing the need for humongous mainframes and allowing the provision of meaningful information to the user like never before. Sounds great, no? Many CIO's believe so, and showed it by `betting the farm' on client-server technology.
This "ground swell" movement is suggesting that a move back to the mainframe might be appropriate. Why? Ifclient-servertechnology is so wonderful, why move back to the mainframe? Why even consider shifting the paradigm back with the cost of losing what the shift was supposed to provide, let alone the cost of the reversal? Why do cubicles have signs like:

Mainframes: We're back, and boy are we ticked off! Aside from the fact that the local mainframe sales representative probably photocopied a stack of them and left them around, what would lead to the display of these signs? There is a perception that the client-server paradigm isn't working. I agree to some extent, but not for any reason that would have me advocate people returning to mainframes, the `art' of 80-column JCL, and data in the form of reams of green-bar paper instead of information.
Let's not lose sight of the Internet earthquake, and the aftershock of Intranets. Lest we forget, both are examples of client-server technology, and there's not a darned thing wrong with it. There are ongoing issues with the application side of client-server technology, but before I discuss the cause and solutions, let me expand on the symptoms of the issue.
Symptoms

  • the technology is expensive to manage
  • the applications are expensive to develop
  • payback is lacking Frankly, these symptoms were common long before client-server technology. The inference is that client-server technology itself is the cause of these symptoms. Untrue. The cause is often that much of the planning and implementation to insert client-server technology into these mainframe environments was done by people who had as much idea about implementing it as does my Clumber spaniel, Bumble (and when you look deep into his eyes ya don't see much client-server knowledge), and sometimes that those responsible for its implementation had considerable motivation (they felt) to not have a successful implementation.
    The truly amazing, and often humorous, slant to all of this is that the client-server naysayers seem oblivious not only to the fact that client-server technology is enjoying an enormous success, but that often this success is happening right in their `living room.' They look at the PC with the order-processing application connected to a server and say that it should move back to the mainframe, but all around their company people are using the Internet, and possibly an intranet, and the fact is folks that the whole technology of web pages on a World-Wide Web, in the case of the Internet, or on an intra-company server, in the case of an intranet, is client-server technology! I think that needs to be stated again:
    The Internet and intranets are the successful embodiment of client-server technology! There, the secret is out. Yet nobody is screaming about the Internet not working. No one is saying that intranets are a waste of time. Just the opposite is happening - Internet Service Provider (ISP) stocks are increasing steadily and anything having to do with the Internet from add-on applications to magazines seem to be a gold mine. Is it simply because the technology is so new that no one understands it yet? Nope. So why are the client-server applications getting bad press? Let's go back to looking through the eyes of Bumble the Wonder Dog. What happens when you launch into anything major in life with the combination of insufficient information and little experience? Consider that combination coming to bear in constructing a house or starting a business: would you want to live in it or work for it?
    Let's take a look at why these problems are really arising.
    1. Politics and empire. Don't underestimate it. He who held the mainframe held the power. In many cases the power base of a distributed computer system, as is the case with client-server, is unclear. So there are instances where the `emperor' is concerned with diluting the powerbase and so, despite giving the go-ahead on a client-server project due to politics there is no desire for that environment to succeed. In other cases, political opponents of a well-meaning CIO (Chief Information Officer) see the large-scale implementation of new technology as opportunity for a covert toppling of the existing powerbase.
    2. CIO's are being misled, intentionally or unintentionally, about the return on investment of client-server technology. The fact is that the technology and development using it have a front-end loaded cost. Implementing an environment of new technology is always costly, as is the learning curve and configuring of the development environment. New equipment has to be purchased; new infrastructure developed or the current infrastructure heavily modified; libraries, databases and objects need to be designed before anything is rolled out let alone a return realized. Therefore, the ROI (return on investment) is weighted towards the back-end on a timeline.
    3. People are losing sight of the biggest ROI ( eliminating the huge mainframe dinosaur. The intention, when the environment is agreed to, is usually to develop a migration plan to get off the dinosaur. What happens very often though is that an inordinate amount of time ends up being spent on GUI's (graphical user interfaces) for applications because they're visual, have immediate impact, and feeds our apparently inherent need for creeping elegance. So the user ends up with just an e-mail system with an above-average paint job, though the billing and purchasing systems are still on the mainframe, thus leaving the mainframe expense intact.
    4. Infrastructure. Hardly anyone is giving it the proper consideration. You might be able to force a round peg into a square hole, but then both the hole and the peg become fairly useless. The thought very often is "the mainframe infrastructure has existed for years - let's use it." Well, you may not be able to bend and shape it enough without major changes - even a Slinky(r) has limits to its adaptability.
    5. Deployment. There are many approaches to deployment, especially when those deploying are unfamiliar with the technology. Often brute force is used. It works, but not well, and can result in positioning the landscape of a very different ROI model without anyone realizing it.
    Given these points of potential failure, I should now provide my rationale in developing this book, and first, why I felt what I have to say is worth reading.
    I began managing enterprise-wide rollouts fifteen years ago. I didn't make a conscious decision to enter this arena; I was a software developer and stumbled into it. At that time the new paradigm was mini-computers used for financial, order processing, manufacturing, and so on. Having designed a research and manufacturing application for a chemical coatings company, I found myself responsible for implementing the technology and applications at multiple sites. Many of the issues in that rollout arose in every subsequent one, albeit with different faces and packaging, and had nothing to do with the application itself, but instead the infrastructure necessary to support it. Through the many implementations I have planned and managed since then, with magnitudes ranging from a handful of systems to upwards of a thousand, and clients including telecom corporations, two of the largest retailers, and a major media corporation, I've developed what has been for me a sanity-saving approach.
    It's the approach I want to pass on to you, and a case study and specific technology example is the method I'll be using. Back in my college days my roommate and I made the not-so-bright decision to drive from our school in Connecticut to his friend's school in New Hampshire, during a frigid New England winter, in a car without a working heater. I remember us slip-sliding along what looked like a small highway on the map, but in reality translated to a path through the mountains. We stopped at a roadside general store and I asked an old gentleman for directions (yes, honey, I actually did that once). He responded with the classic, "Ayuh, ya can't get there from here." Well, looking around at your environment, and then looking at an environment where client-server applications are being used to their potential, including the use of an intranet, might leave you feeling that you can't get there from here, but you can, and I'm going to try to give you directions. I'll also try to provide a map of the pitfalls along the way. At times it might sound very negative, but that's only because all the pitfalls need to be mentioned, even though you might not experience them, while the good stuff that will hopefully happen to you along the way is left to your imagination.
    The bottom line: plan for the planning. Because most of the issues facing an enterprise-wide rollout are repetitive, there exists the ability to plan for their identification before ever walking into the conference room for your first team meeting. Having a clear approach that you're comfortable with will enable you to start off with confidence ( the mark of a leader.
    There's another story about a New England codger, this one in Maine. It seems that a couple from New Hampshire were thinking of moving to Maine (they were probably tired of "not being able to get there from here.") They knew that in most small towns in New England, if you weren't born there you were considered to be "from away," even after twenty-five years of residency. The mother was expecting, and was determined not to have her child grow up being "from away." So when she went into labor, she had her husband drive her to the town in Maine and gave birth there. Later, after having moved and settled in, she was recounting the story to someone in the local general store. An old codger rocking in his chair outside the screen door overheard the story, and when the mother finished the story by expressing that since her son was born there he was a local, the man piped up with, "Ayuh, but a cat crawling into the oven to have her kittens doesn't make them muffins."
    Replacing a successful, existing application with a well-written client-server application doesn't necessarily mean the new application will be successful, but after reading this book, my hopes are that you'll understand what ghosties and ghoulies stand in your way, and what it will take to be successful. And that the understanding of how to be successful will help you to move on to navigating through the fear, uncertainty, and doubt to determine what applications and approach have a chance at being successful after being implemented. Plan well; don't stumble when the paradigm shifts.


    I hope you enjoy reading A Methodology for Developing and Deploying Internet and Intranet Solutions.
    Jeff R. Greenberg Manager, Telecom Solutions Support Program HP Professional Services Organization Atlanta, Georgia May, 1996
Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)