Release it! Software engineering and design for those who care

    Hello, habrozhiteli!
    We have a book by Michael Neygard

    image

    It doesn't matter which tool you use for software development - Java, .NET, or Ruby on Rails. Writing code is only half the battle. Are you ready for a sudden influx of bots to your site? Does your software include “fool protection”? Do you understand usability right? Michael Neigard argues that most of the problems in software products were embedded in them at the design and engineering stage. You can move to the ideal yourself - by trial and error, or you can use the experience of the author. In this book you will find many design patterns that help to avoid critical situations, and no less anti-patterns that illustrate the wrong approaches with a detailed analysis of the possible consequences. Any developer with experience in multi-threaded programming will easily understand the examples in Java,
    Stability, security and a user-friendly interface are the three most important components of the success of your software product. If your plans do not include over the next years to respond to dissatisfied letters from users, listen to criticism of customers and constantly patch up holes, eliminating bugs, then read this book before releasing the final release.


    Who is this book for?

    I wrote this book for architects, designers, and enterprise-class software developers, including sites, web services, and EAI projects. For me, enterprise-class software means that the application must work, otherwise the company will lose money. This category includes both commercial systems that are directly related to generating income, for example, through sales, and important internal corporate systems that are necessary for fulfilling the employees ’work responsibilities. If the failure of your program can leave a person without work for the whole day, then this book is intended for you.

    Book structure

    The book is divided into four parts, each of which begins with a practical example. Part I shows how to keep the system active, ensuring its trouble-free operation. Despite the promised reliability due to redundancy, distributed systems demonstrate availability expressed by “two eights” rather than the desired “five nines” (That is 88, not 99,999% uptime).

    A prerequisite for considering any other issues is stability. If your system crashes several times a day, no one will consider aspects related to the distant future. In such an environment, short-term corrections and, as a result, short-term thinking dominate. Without stability, there will be no competitive future, so the first thing to understand is how you can guarantee the stability of the basic system, which will serve as the basis for further work.

    Once you achieve stability, it's time to take care of the power of the system. Part II is devoted to this topic, in which you will get acquainted with the methods of measuring this parameter, find out what it really means, and learn how to optimize it in the long run. I will show you examples of patterns and antipatterns that illustrate good and bad design decisions, and demonstrate the amazing impact that these decisions can have on computing power (and, as a consequence, on the number of nightly phone calls and messages).

    In Part III, we will discuss general design issues that an architect must consider when writing programs for data centers. Over the past decade, hardware and infrastructure design have undergone significant changes; for example, such a relatively rare practice before as virtualization is now widespread almost everywhere. Networks have become much more complex - now they are multi-level and programmable. Storage networks have become commonplace. Software development must take into account and use these innovations to ensure the smooth operation of data centers.

    In Part IV, the existence of a system is considered within the framework of a common information ecosystem. Often, production systems resemble the Schrödinger cat - they are locked in a box without the ability to monitor their condition. This does not contribute to ecosystem health. Lack of information makes targeted improvements impossible. Chapter 17 discusses factors, technologies, and processes that should be learned from working systems (this is the only situation where you can learn certain things).

    Having found out the performance and performance indicators of a particular system, you can act on the basis of this data. Moreover, such an approach is mandatory - actions should be taken only in the light of the information received. This is sometimes easier said than done, and in chapter 18 we look at the obstacles to change and how to reduce and overcome them.

    Case Studies

    To illustrate the basic concepts of the book, I gave some detailed examples. They are taken from real life and describe the system failures that I witnessed. These failures turned out to be extremely costly - and incriminating - for those involved. Therefore, I omitted information that would identify specific companies and people. I also changed the names of systems, classes, and methods. But only “non-essential” details were changed. In all cases, I indicated the industry, sequence of events, failure mode, error propagation path, and result. The price of all these failures is not exaggerated. These are real losses of real firms. I mentioned these numbers in the text to emphasize the seriousness of the material. System failure puts real money at risk.

    You can learn more about the book atthe publisher’s website
    Contents
    Excerpt

    For Habrozhitelami 25% discount on coupon - Release it!

    Also popular now: