Release it! Software design and design for those who care
Hi, Habrozhiteli!
We published the book of Michael Neigard
It doesn't matter what tool you use for software development - Java, .NET, or Ruby on Rails. Writing code is only half the battle. Are you ready for the sudden influx of bots to your site? Does your “foolproof” software? Do you understand usability correctly? Michael Neygard argues that most of the problems in software products were laid in them at the design and design 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 a smaller number of anti-patterns that illustrate the wrong approaches with a detailed analysis of the possible consequences. Any developer who has experience in multi-threaded programming can easily figure out the examples given in Java, which are explained and commented in detail.
Stability, security and user-friendly interface - these are the three most important components of the success of your software product. If your plans do not include in subsequent years to respond to dissatisfied letters from users, listen to customer criticism and constantly patch holes, eliminating any bugs that occur, then read this book before releasing the final release.
')
I wrote this book for architects, designers, and enterprise-class software developers, including websites, web services, and EAI projects. For me, enterprise-class software means that the application should work, otherwise the company will lose money. This category includes both commercial systems directly related to income generation, for example, through sales, as well as important internal corporate systems necessary for the performance of employee duties. If the failure of your program can leave a person out of work for a whole day, then this book is for you.
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 accessibility, expressed more by "two eights" than by the desired "five nines" (That is, 88, not 99.999% of uptime).
A prerequisite for the consideration of 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 dominate and, as a result, short-term thinking. Without stability, there will be no competitive future, so the first thing to do is to understand how you can guarantee the stability of the basic system, which will serve as the basis for further work.
Once you achieve stability, it is time to take care of the power of the system. Part II is devoted to this topic, in which you will learn how to measure this parameter, learn what it actually means, and learn how to optimize it in the long term. I will show you examples of patterns and anti-patterns that illustrate good and bad design decisions, and demonstrate the tremendous impact that these decisions can have on computing power (and, as a result, on the number of overnight phone calls and messages).
In Part III, we will look at general design issues that an architect must consider when writing programs for data centers. Over the past decade, the hardware and infrastructure design have undergone significant changes; For example, such a relatively rare earlier practice, like virtualization, is now common almost everywhere. Networks have become much more complicated - now they are multi-layered and programmable. Networking has become commonplace. Software development should take into account and use these innovations to ensure the smooth operation of data centers.
In Part IV, the existence of the system is considered within the framework of a common information ecosystem. Often, production systems resemble Schrödinger's cat - they are locked in a box without being able to monitor their condition. It does not contribute to the health of the ecosystem. Lack of information makes targeted improvements impossible. Chapter 17 discusses the factors, technologies, and processes that should be learned from operating systems (this is the only situation where certain things can be studied).
After finding out the performance and performance of a particular system, you can act on the basis of this data. Moreover, such an approach is obligatory - actions should be taken only in the light of the information received. Sometimes this is easier said than done, and in Chapter 18 we look at the obstacles to change and how to reduce and overcome them.
To illustrate the basic concepts of the book, I gave a few 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 compromising - for those who had to do with them. Therefore, I omitted information that would identify specific companies and people. I also changed the names of systems, classes and methods. But only “insignificant” details were changed. In all cases, I have indicated the industry, the sequence of events, the failure mode, the propagation path of the error, and the 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.
More information about the book can be found on the publisher's website.
Table of contents
Excerpt
For Habrozhiteley a 25% discount on the coupon - Release it!
We published the book of Michael Neigard
It doesn't matter what tool you use for software development - Java, .NET, or Ruby on Rails. Writing code is only half the battle. Are you ready for the sudden influx of bots to your site? Does your “foolproof” software? Do you understand usability correctly? Michael Neygard argues that most of the problems in software products were laid in them at the design and design 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 a smaller number of anti-patterns that illustrate the wrong approaches with a detailed analysis of the possible consequences. Any developer who has experience in multi-threaded programming can easily figure out the examples given in Java, which are explained and commented in detail.
Stability, security and user-friendly interface - these are the three most important components of the success of your software product. If your plans do not include in subsequent years to respond to dissatisfied letters from users, listen to customer criticism and constantly patch holes, eliminating any bugs that occur, 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 websites, web services, and EAI projects. For me, enterprise-class software means that the application should work, otherwise the company will lose money. This category includes both commercial systems directly related to income generation, for example, through sales, as well as important internal corporate systems necessary for the performance of employee duties. If the failure of your program can leave a person out of work for a whole day, then this book is 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 accessibility, expressed more by "two eights" than by the desired "five nines" (That is, 88, not 99.999% of uptime).
A prerequisite for the consideration of 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 dominate and, as a result, short-term thinking. Without stability, there will be no competitive future, so the first thing to do is to understand how you can guarantee the stability of the basic system, which will serve as the basis for further work.
Once you achieve stability, it is time to take care of the power of the system. Part II is devoted to this topic, in which you will learn how to measure this parameter, learn what it actually means, and learn how to optimize it in the long term. I will show you examples of patterns and anti-patterns that illustrate good and bad design decisions, and demonstrate the tremendous impact that these decisions can have on computing power (and, as a result, on the number of overnight phone calls and messages).
In Part III, we will look at general design issues that an architect must consider when writing programs for data centers. Over the past decade, the hardware and infrastructure design have undergone significant changes; For example, such a relatively rare earlier practice, like virtualization, is now common almost everywhere. Networks have become much more complicated - now they are multi-layered and programmable. Networking has become commonplace. Software development should take into account and use these innovations to ensure the smooth operation of data centers.
In Part IV, the existence of the system is considered within the framework of a common information ecosystem. Often, production systems resemble Schrödinger's cat - they are locked in a box without being able to monitor their condition. It does not contribute to the health of the ecosystem. Lack of information makes targeted improvements impossible. Chapter 17 discusses the factors, technologies, and processes that should be learned from operating systems (this is the only situation where certain things can be studied).
After finding out the performance and performance of a particular system, you can act on the basis of this data. Moreover, such an approach is obligatory - actions should be taken only in the light of the information received. Sometimes this is easier said than done, and in Chapter 18 we look at the obstacles to change and how to reduce and overcome them.
Case study
To illustrate the basic concepts of the book, I gave a few 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 compromising - for those who had to do with them. Therefore, I omitted information that would identify specific companies and people. I also changed the names of systems, classes and methods. But only “insignificant” details were changed. In all cases, I have indicated the industry, the sequence of events, the failure mode, the propagation path of the error, and the 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.
More information about the book can be found on the publisher's website.
Table of contents
Excerpt
For Habrozhiteley a 25% discount on the coupon - Release it!
Source: https://habr.com/ru/post/266417/
All Articles