emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Я продолжу. В процессе обсуждения возник аргумент, что mental model, служащая для описания и выравнивания понимания того, что происходит в problem space, все-таки отличается от модели решения (solution space). Свидетельство этого можно обнаружить, например…
Что такое модель по SEBoK:
🔷 https://sebokwiki.org/wiki/Model_(glossary)
🔷 https://sebokwiki.org/wiki/What_is_a_Model%3F
🔷 https://sebokwiki.org/wiki/Types_of_Models
🔷 https://sebokwiki.org/wiki/Why_Model%3F
Что такое концептуальная модель:
🔷 https://sebokwiki.org/wiki/System_Modeling_Concepts#Conceptual_Model
🔷 https://sebokwiki.org/wiki/Concept_(glossary)
См. также...
🔷 https://sebokwiki.org/wiki/Model_(glossary)
🔷 https://sebokwiki.org/wiki/What_is_a_Model%3F
🔷 https://sebokwiki.org/wiki/Types_of_Models
🔷 https://sebokwiki.org/wiki/Why_Model%3F
Что такое концептуальная модель:
🔷 https://sebokwiki.org/wiki/System_Modeling_Concepts#Conceptual_Model
🔷 https://sebokwiki.org/wiki/Concept_(glossary)
См. также...
Forwarded from Russian Association of Software Architects (Ivan Zakrevsky)
Eric Evans дает интересное определение Constantine's Law нетехническим языком:
💬 "МОДУЛИ дают возможность посмотреть на модель с разных сторон:
во-первых, можно изучить подробности устройства модуля, не вникая в сложное целое;
во-вторых, удобно рассматривать взаимоотношения между модулями, не вдаваясь в детали их внутреннего устройства.
<...>
То, что при делении на модули должна соблюдаться низкая внешняя зависимость
(low coupling) при высокой внутренней связности (high cohesion)- это общие слова. Определения зависимости и связности грешат уклоном в чисто технические, количественные критерии, по которым их якобы можно измерить, подсчитав количество ассоциаций и взаимодействий. Но это не просто механические характеристики подразделения кода на модули, а идейные концепции. Человек не может одновременно удерживать в уме слишком много предметов (отсюда низкая внешняя зависимость). А плохо связанные между собой фрагменты информации так же трудно понять, как неструктурированную "кашу" из идей (отсюда высокая внутренняя связность).
MODULES give people two views of the model:
They can look at detail within a MODULE without being overwhelmed by the whole, or they can look at relationships between MODULES in views that exclude interior detail.
<...>
It is a truism that there should be low coupling between MODULES and high cohesion
within them. Explanations of coupling and cohesion tend to make them sound like technical metrics, to be judged mechanically based on the distributions of associations and interactions. Yet it isn't just code being divided into MODULES, but concepts. There is a limit to how many things a person can think about at once (hence low coupling). Incoherent fragments of ideas are as hard to understand as an undifferentiated soup of ideas (hence high cohesion)."
-- "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans, перевод В.Л. Бродового
#SoftwareDesign
💬 "МОДУЛИ дают возможность посмотреть на модель с разных сторон:
во-первых, можно изучить подробности устройства модуля, не вникая в сложное целое;
во-вторых, удобно рассматривать взаимоотношения между модулями, не вдаваясь в детали их внутреннего устройства.
<...>
То, что при делении на модули должна соблюдаться низкая внешняя зависимость
(low coupling) при высокой внутренней связности (high cohesion)- это общие слова. Определения зависимости и связности грешат уклоном в чисто технические, количественные критерии, по которым их якобы можно измерить, подсчитав количество ассоциаций и взаимодействий. Но это не просто механические характеристики подразделения кода на модули, а идейные концепции. Человек не может одновременно удерживать в уме слишком много предметов (отсюда низкая внешняя зависимость). А плохо связанные между собой фрагменты информации так же трудно понять, как неструктурированную "кашу" из идей (отсюда высокая внутренняя связность).
MODULES give people two views of the model:
They can look at detail within a MODULE without being overwhelmed by the whole, or they can look at relationships between MODULES in views that exclude interior detail.
<...>
It is a truism that there should be low coupling between MODULES and high cohesion
within them. Explanations of coupling and cohesion tend to make them sound like technical metrics, to be judged mechanically based on the distributions of associations and interactions. Yet it isn't just code being divided into MODULES, but concepts. There is a limit to how many things a person can think about at once (hence low coupling). Incoherent fragments of ideas are as hard to understand as an undifferentiated soup of ideas (hence high cohesion)."
-- "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans, перевод В.Л. Бродового
#SoftwareDesign
👍1
Forwarded from Архитектура ИТ-решений
В официальном твиттер-аккаунте The Open Group, посвященном ArchiMate, позавчера снова появилась ссылка на кликабельный Language Notation Guide
👍3
Forwarded from Stanislav Bolsun
When you are just getting started in your software modeling efforts, your Bounded Context is
somewhat conceptual. You could think of it as part of your problem space. However, as your model
starts to take on deeper meaning and clarity, your Bounded Context will quickly transition to your
solution space , with your software model being reflected as project source code. (The problem
space and solution space are better explained in the box.) Remember that a Bounded Context is
where a model is implemented, and you will have separate software artifacts for each Bounded
Context.
и
The best Ubiquitous Language will be developed by a collaborative feedback loop
that drives out the combined mental model of the team. Open conversation, exploration, and
challenges to your current knowledge base result in deeper insights about the Core Domain.
интересная мысль у Вернона в distilling DDD
somewhat conceptual. You could think of it as part of your problem space. However, as your model
starts to take on deeper meaning and clarity, your Bounded Context will quickly transition to your
solution space , with your software model being reflected as project source code. (The problem
space and solution space are better explained in the box.) Remember that a Bounded Context is
where a model is implemented, and you will have separate software artifacts for each Bounded
Context.
и
The best Ubiquitous Language will be developed by a collaborative feedback loop
that drives out the combined mental model of the team. Open conversation, exploration, and
challenges to your current knowledge base result in deeper insights about the Core Domain.
интересная мысль у Вернона в distilling DDD
🔥3
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
When you are just getting started in your software modeling efforts, your Bounded Context is somewhat conceptual. You could think of it as part of your problem space. However, as your model starts to take on deeper meaning and clarity, your Bounded Context…
В этом тексте Vaughn Vernon поясняет, почему Domain Model по своему названию относится к области проблемы, а на самом деле - к области решения. В общем, он подтверждает правильность моих выводов.
В DDD немало таких логических противоречий, что затрудняет его освоение, но не уменьшает его практической ценности. Некоторые из них были описаны в этой статье.
В DDD немало таких логических противоречий, что затрудняет его освоение, но не уменьшает его практической ценности. Некоторые из них были описаны в этой статье.
Telegram
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
When you are just getting started in your software modeling efforts, your Bounded Context is
somewhat conceptual. You could think of it as part of your problem space. However, as your model
starts to take on deeper meaning and clarity, your Bounded Context…
somewhat conceptual. You could think of it as part of your problem space. However, as your model
starts to take on deeper meaning and clarity, your Bounded Context…
❤1👍1🔥1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
В этом тексте Vaughn Vernon поясняет, почему Domain Model по своему названию относится к области проблемы, а на самом деле - к области решения. В общем, он подтверждает правильность моих выводов. В DDD немало таких логических противоречий, что затрудняет…
Как вы считаете, какие последствия наступают, если команда не понимает, что такое модель, как её формировать и определять её границы? Нужна ли вообще вся эта "академичность"? Живут же как-то без этого... Напишите своё мнение.
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
В этом тексте Vaughn Vernon поясняет, почему Domain Model по своему названию относится к области проблемы, а на самом деле - к области решения. В общем, он подтверждает правильность моих выводов. В DDD немало таких логических противоречий, что затрудняет…
💬 The traditional software development lifecycle implies the following translations:
- Domain knowledge into an analysis model
- Analysis model into requirements
- Requirements into system design
- System design into source code
Instead of continuously translating domain knowledge, domain-driven design calls for cultivating a single language for describing the business domain: the ubiquitous language.
...
Modeling the Business Domain
When cultivating a ubiquitous language, we are effectively building a model of the business domain. The model is supposed to capture the domain experts’ mental models—their thought processes about how the business works to implement its function. The model has to reflect the involved business entities and their behavior, cause and effect relationships, and invariants.
The ubiquitous language we use is not supposed to cover every possible detail of the domain. That would be equivalent to making every stakeholder a domain expert. Instead, the model is supposed to include just enough aspects of the business domain to make it possible to implement the required system; that is, to address the specific problem the software is intended to solve. In the following chapters, you will see how the ubiquitous language can drive low-level design and implementation decisions.
-- Learning DDD by Vladik Khononov
- Domain knowledge into an analysis model
- Analysis model into requirements
- Requirements into system design
- System design into source code
Instead of continuously translating domain knowledge, domain-driven design calls for cultivating a single language for describing the business domain: the ubiquitous language.
...
Modeling the Business Domain
When cultivating a ubiquitous language, we are effectively building a model of the business domain. The model is supposed to capture the domain experts’ mental models—their thought processes about how the business works to implement its function. The model has to reflect the involved business entities and their behavior, cause and effect relationships, and invariants.
The ubiquitous language we use is not supposed to cover every possible detail of the domain. That would be equivalent to making every stakeholder a domain expert. Instead, the model is supposed to include just enough aspects of the business domain to make it possible to implement the required system; that is, to address the specific problem the software is intended to solve. In the following chapters, you will see how the ubiquitous language can drive low-level design and implementation decisions.
-- Learning DDD by Vladik Khononov
👍4❤1🔥1
В 2022 году я думал, как хорошо, что в РФ есть такая компания как Яндекс, которая обеспечивает технологическую независимость страны. Как я тогда ошибался. Нет ничего хуже монополии в условиях безальтернативности, которая приводит к полной зависимости от прихоти монополиста. Про цены на Яндекс.Такси, который выкупил почти всех своих ключевых конкурентов, на сегодняшний день не написал только ленивый. Яндекс.Такси вверг меня в середину 90-х - бордюрщики и заказы по телефону местячкового такси по спальному району Москвы вновь стали обычной практикой в то время, как человечество научилось управлять транспортным средством силой мысли. Прогресс корпорации Яндекс налицо. Но еще больше меня поразило не это.
Никогда не думал, что в наше время поставщик услуг может без согласия клиента в прямом смысле залезть к нему в карман, самовольно по своей прихоти установить любой тарифный план и списать любую сумму денег без права на апелляцию. Но еще удивительней то, что отключить навязанный тариф технически невозможно - кнопка отписки просто неактивна. Так же технически невозможно открепить карту или отписаться от подписки на Плюс полностью - такая возможность просто отсутствует в пользовательском интерфейсе. Попытки отписаться от навязанного тарифа и вернуть свой тариф (который актуальный, не архивный) обернулись тем, что теперь активно аж два навязанных тарифа, причем, второй из них - по промокоду, который никто не вводил. И все это по цене, по которой я на Wink получаю в три раза больше (шесть кинотеатров одновременно вместо двух).
Первой под снос пошла Яндекс.Клавиатура. За вчерашний день половина моих поездок была на Сити.Мобил и на бордюрщиках. Да, приходится дольше ждать и не всегда удается вообще дождаться, но теперь это вопрос принципа - в рыночной экономике просто обязана быть здоровая конкуренция, которую иногда нужно поддержать, чтоб никто не зажрался. Постепенно исключаю Яндекс из своей жизни. Petal.Maps вместо Яндекс.Карт. Акции Яндекса - только в шорт. И я счастлив, что хотя бы бордюрщики бросили вызов конкуренции "самой высокотехнологичной компании страны".
Извините за оффтоп.
Никогда не думал, что в наше время поставщик услуг может без согласия клиента в прямом смысле залезть к нему в карман, самовольно по своей прихоти установить любой тарифный план и списать любую сумму денег без права на апелляцию. Но еще удивительней то, что отключить навязанный тариф технически невозможно - кнопка отписки просто неактивна. Так же технически невозможно открепить карту или отписаться от подписки на Плюс полностью - такая возможность просто отсутствует в пользовательском интерфейсе. Попытки отписаться от навязанного тарифа и вернуть свой тариф (который актуальный, не архивный) обернулись тем, что теперь активно аж два навязанных тарифа, причем, второй из них - по промокоду, который никто не вводил. И все это по цене, по которой я на Wink получаю в три раза больше (шесть кинотеатров одновременно вместо двух).
Первой под снос пошла Яндекс.Клавиатура. За вчерашний день половина моих поездок была на Сити.Мобил и на бордюрщиках. Да, приходится дольше ждать и не всегда удается вообще дождаться, но теперь это вопрос принципа - в рыночной экономике просто обязана быть здоровая конкуренция, которую иногда нужно поддержать, чтоб никто не зажрался. Постепенно исключаю Яндекс из своей жизни. Petal.Maps вместо Яндекс.Карт. Акции Яндекса - только в шорт. И я счастлив, что хотя бы бордюрщики бросили вызов конкуренции "самой высокотехнологичной компании страны".
Извините за оффтоп.
👍53😁16🔥4
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Про оценивание задач: - "Practice Standard for Scheduling" 3d edition by Project Management Institute "Practice Standard for Project Estimating" 2d edition Project Management Institute - "Software Estimation: Demystifying the Black Art (Developer Best Practices)"…
Что такое оценка? Как её выразить? Очень хорошая краткая статья:
"How to Read Lead Time Distribution" by Mauvisoft Team
"How to Read Lead Time Distribution" by Mauvisoft Team
❤2👍2🔥1
Forwarded from Stanislav Bolsun
очень подробно описано все в книге - Domain Modeling Made Functional
(про ДДД)
(про ДДД)
Forwarded from Stanislav Bolsun
Understanding the problem doesn’t mean that building a solution is easy. The solution can’t possibly represent all the information in the original domain, nor would we want it to. We should only capture the information that is rele- vant to solving a particular problem. Everything else is irrelevant.
We therefore need to create a distinction between a “problem space” and a “solution space,” and they must be treated as two different things. To build the solution we will create a model of the problem domain, extracting only the aspects of the domain that are relevant and then re-creating them in our solution space as shown in the figure on page 17.
We therefore need to create a distinction between a “problem space” and a “solution space,” and they must be treated as two different things. To build the solution we will create a model of the problem domain, extracting only the aspects of the domain that are relevant and then re-creating them in our solution space as shown in the figure on page 17.
🔥1
Forwarded from Stanislav Bolsun
---
That means that things in our design must represent real things in the domain expert’s mental model. That is, if the domain expert calls something an “order,” then we should have something called an Order in the code that corresponds to it and that behaves the same way.
And conversely, we should not have things in our design that do not represent something in the domain expert’s model. That means no terms like OrderFactory, OrderManager, OrderHelper, and so forth. A domain expert wouldn’t know what you meant by these words. Of course, some technical terms will have to occur in the codebase, but you should avoid exposing them as part of the design.
The set of concepts and vocabulary that is shared between everyone on the team is called the Ubiquitous Language—the “everywhere language.” This is the language that defines the shared mental model for the business domain. And, as its name implies, this language should used everywhere in the project, not just in the requirements but in the design and, most importantly, in the source code.
That means that things in our design must represent real things in the domain expert’s mental model. That is, if the domain expert calls something an “order,” then we should have something called an Order in the code that corresponds to it and that behaves the same way.
And conversely, we should not have things in our design that do not represent something in the domain expert’s model. That means no terms like OrderFactory, OrderManager, OrderHelper, and so forth. A domain expert wouldn’t know what you meant by these words. Of course, some technical terms will have to occur in the codebase, but you should avoid exposing them as part of the design.
The set of concepts and vocabulary that is shared between everyone on the team is called the Ubiquitous Language—the “everywhere language.” This is the language that defines the shared mental model for the business domain. And, as its name implies, this language should used everywhere in the project, not just in the requirements but in the design and, most importantly, in the source code.
Forwarded from Stanislav Bolsun
In the first chapter, when we were talking about the importance of a shared mental model, we emphasized that the code must also reflect this shared model and that a developer should not have to do lossy translations between the domain model and the source code.
❤1
Это очень важная информация, которая, к сожалению, очень слабо освещена и многим непонятна. Как результат - очень многие не понимают о том, что такое DDD и зачем он вообще нужен. Практически никто не может объяснить своими словами что такое DDD (на самом деле почти никто не может даже привести формальное определение, которое не сильно добавляет ясности).
Слова Scott Wlaschin - ещё один источник, подтверждающий правильность моих выводов, озвученных ранее.
DDD - это сокращение дивергенции между ментальной (концептуальной) моделью и моделью решения. По сути дела, это их объединение, т.е. построение модели решения на подмножестве ментальной модели, и именно это и называется ubiquitous language.
Слова Scott Wlaschin - ещё один источник, подтверждающий правильность моих выводов, озвученных ранее.
DDD - это сокращение дивергенции между ментальной (концептуальной) моделью и моделью решения. По сути дела, это их объединение, т.е. построение модели решения на подмножестве ментальной модели, и именно это и называется ubiquitous language.
Telegram
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
🔥10
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Об инструментах управления процессами гибридной SDLC-модели разработки небольших проектов. Почему меня интересует гибридная модель? По двум причинам: 1. Небольшие проекты имеют, как правило, низкий уровень неопределенности, а значит баланс Prediction/Adaptation…
Taiga переписан на актуальной версии Django и Angular:
https://github.com/taigaio/taiga
Если вдруг кто пощупает вживую, поделитесь отзывом, пожалуйста.
https://github.com/taigaio/taiga
Если вдруг кто пощупает вживую, поделитесь отзывом, пожалуйста.
GitHub
GitHub - kaleidos-ventures/taiga: Taiga is a free and open-source project management for cross-functional agile teams.
Taiga is a free and open-source project management for cross-functional agile teams. - kaleidos-ventures/taiga
🔥6👍2
Общался на днях со своим коллегой - невероятно грамотным человеком. И он помог мне сделать для себя открытие.
В пабликах часто обсуждается проблема о том, что "рефакторить некогда, нужно сделать всё на вчера", и команда безуспешно пытается найти хоть какое-то понимание со стороны бизнеса в упорядочивании стремительно разбегающейся по коду лапши, в которой она уже успела несколько раз запутаться.
Пропущу длинную цепочку умозаключений, скажу только вывод. Пытаться "продать" решение в таком случае, действительно, может оказаться бесполезно. Вместо этого нужно наладить планирование разработки. Да, пусть план будет долгим, корявым и неточным, но он должен быть, т.к. именно он может снять те самые когнитивные искажения, на основе которых формируются иррациональные решения ЛПР.
Животворящая книга в этом вопросе - это "Planning Extreme Programming" by Kent Beck, Martin Fowler, которая хорошо раскрывает тему о том, почему бесполезно убеждать ЛПР в условиях отсутствия планирования.
[UPDATE]: об инструментах планирования:
- https://news.1rj.ru/str/emacsway_log/1079
- https://news.1rj.ru/str/emacsway_log/1081
- https://news.1rj.ru/str/emacsway_log/1098
О методах планирования и оценивания:
- https://news.1rj.ru/str/emacsway_log/916
В пабликах часто обсуждается проблема о том, что "рефакторить некогда, нужно сделать всё на вчера", и команда безуспешно пытается найти хоть какое-то понимание со стороны бизнеса в упорядочивании стремительно разбегающейся по коду лапши, в которой она уже успела несколько раз запутаться.
Пропущу длинную цепочку умозаключений, скажу только вывод. Пытаться "продать" решение в таком случае, действительно, может оказаться бесполезно. Вместо этого нужно наладить планирование разработки. Да, пусть план будет долгим, корявым и неточным, но он должен быть, т.к. именно он может снять те самые когнитивные искажения, на основе которых формируются иррациональные решения ЛПР.
Животворящая книга в этом вопросе - это "Planning Extreme Programming" by Kent Beck, Martin Fowler, которая хорошо раскрывает тему о том, почему бесполезно убеждать ЛПР в условиях отсутствия планирования.
[UPDATE]: об инструментах планирования:
- https://news.1rj.ru/str/emacsway_log/1079
- https://news.1rj.ru/str/emacsway_log/1081
- https://news.1rj.ru/str/emacsway_log/1098
О методах планирования и оценивания:
- https://news.1rj.ru/str/emacsway_log/916
🔥6👍5❤🔥1
Forwarded from Блог Сергея Баранова (Sergey Baranov)
Требования безопасности.pdf
121.5 KB
Нашел в архиве требования безопасности, уж не помню к какому точно проекту формулировал, еще в 2012-м году, может кому-то будет полезно.
Делайте скидку на то, что это было почти 12 лет назад, появились новые угрозы, но что-то почерпнуть точно можно :)
Делайте скидку на то, что это было почти 12 лет назад, появились новые угрозы, но что-то почерпнуть точно можно :)
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Общался на днях со своим коллегой - невероятно грамотным человеком. И он помог мне сделать для себя открытие. В пабликах часто обсуждается проблема о том, что "рефакторить некогда, нужно сделать всё на вчера", и команда безуспешно пытается найти хоть какое…
В продолжение темы планирования.
Вот что пишет Дейл Карнеги в своей книге "Как перестать беспокоиться":
💬 Сорок два года спустя, в тихий весенний вечер, когда в университетском парке цвели тюльпаны, сэр Уильям Ослер обратился к студентам Йельского университета. Считается, сказал он, что такой человек, как он,- профессор четырех университетов и автор популярной книги, должен обладать «мозгом особого качества». Это неверно, заявил он. Оказывается, и его близкие друзья знали, что он обладал «самыми посредственными способностями». В чем же секрет его успеха? Он сказал, что достиг успеха потому, что стремился жить в отсеке сегодняшнего дня, непроницаемо отгороженном от остальных дней. Что он имел в виду? За несколько месяцев до своего выступления в Йельском университете сэр Уильям Ослер пересек Атлантический океан на большом океанском лайнере, на котором капитан, стоявший на мостике, мог нажать на кнопку, и сразу же слышался шум механизмов, и отдельные отсеки корабля начинали герметически закрываться, чтобы в них не попала вода. «Каждый из вас,- сказал доктор Ослер этим студентам,- является гораздо более замечательным механизмом, чем гигантский лайнер, и, вступив в жизнь, вы отправляетесь в более длительное плавание. Я настаиваю на том, что вы должны научиться контролировать данный вам механизм и защищать его от штормов, то есть вовремя изолировать его отдельные отсеки. Только тогда вы обеспечите безопасность своего путешествия. Стойте на мостике и обеспечьте, чтобы хотя бы главные переборки корабля находились в рабочем состоянии. Нажмите на кнопку, и вы услышите, как на каждом этапе вашей жизни железные двери изолируют от вас прошлое - мертвые вчерашние дни. Нажмите на другую кнопку, и металлический занавес изолирует будущее - не родившиеся завтрашние дни. Тогда вы в полной безопасности - на сегодняшний день!.. Изолируйте прошлое! Пусть мертвое прошлое хоронит своих мертвецов... Изолируйте вчерашние дни, которые освещали глупцам путь к могиле. Груз будущего, прибавленный к грузу прошлого, который вы взваливаете на себя в настоящем, заставляет спотыкаться на пути даже самых сильных. Изолируйте будущее так же герметически, как прошлое... Будущее в настоящем... Нет завтра. День спасения человека - сегодня. Бессмысленная трата энергии, душевные страдания, нервное беспокойство неотступно следуют по пятам человека, который беспокоится о будущем... Итак, закройте наглухо все отсеки корабля, отделите носовую и кормовую части лайнера железными переборками. Воспитывайте у себя привычку жить в отрезке времени, отделенном от прошлого и будущего „герметическими переборками".
Разве доктор Ослер хотел сказать, что мы не должны прилагать никаких усилий для подготовки к завтрашнему дню? Нет. Отнюдь нет. Он лишь неустанно утверждал в этом выступлении, что лучший способ подготовиться к завтрашнему дню - сконцентрировать свои силы и способности на наилучшем выполнении сегодняшних дел."
-- "Как перестать беспокоиться и начать жить." / Дейл Карнеги, Перевод с английского З. П. Вольской.
Вот что пишет Дейл Карнеги в своей книге "Как перестать беспокоиться":
💬 Сорок два года спустя, в тихий весенний вечер, когда в университетском парке цвели тюльпаны, сэр Уильям Ослер обратился к студентам Йельского университета. Считается, сказал он, что такой человек, как он,- профессор четырех университетов и автор популярной книги, должен обладать «мозгом особого качества». Это неверно, заявил он. Оказывается, и его близкие друзья знали, что он обладал «самыми посредственными способностями». В чем же секрет его успеха? Он сказал, что достиг успеха потому, что стремился жить в отсеке сегодняшнего дня, непроницаемо отгороженном от остальных дней. Что он имел в виду? За несколько месяцев до своего выступления в Йельском университете сэр Уильям Ослер пересек Атлантический океан на большом океанском лайнере, на котором капитан, стоявший на мостике, мог нажать на кнопку, и сразу же слышался шум механизмов, и отдельные отсеки корабля начинали герметически закрываться, чтобы в них не попала вода. «Каждый из вас,- сказал доктор Ослер этим студентам,- является гораздо более замечательным механизмом, чем гигантский лайнер, и, вступив в жизнь, вы отправляетесь в более длительное плавание. Я настаиваю на том, что вы должны научиться контролировать данный вам механизм и защищать его от штормов, то есть вовремя изолировать его отдельные отсеки. Только тогда вы обеспечите безопасность своего путешествия. Стойте на мостике и обеспечьте, чтобы хотя бы главные переборки корабля находились в рабочем состоянии. Нажмите на кнопку, и вы услышите, как на каждом этапе вашей жизни железные двери изолируют от вас прошлое - мертвые вчерашние дни. Нажмите на другую кнопку, и металлический занавес изолирует будущее - не родившиеся завтрашние дни. Тогда вы в полной безопасности - на сегодняшний день!.. Изолируйте прошлое! Пусть мертвое прошлое хоронит своих мертвецов... Изолируйте вчерашние дни, которые освещали глупцам путь к могиле. Груз будущего, прибавленный к грузу прошлого, который вы взваливаете на себя в настоящем, заставляет спотыкаться на пути даже самых сильных. Изолируйте будущее так же герметически, как прошлое... Будущее в настоящем... Нет завтра. День спасения человека - сегодня. Бессмысленная трата энергии, душевные страдания, нервное беспокойство неотступно следуют по пятам человека, который беспокоится о будущем... Итак, закройте наглухо все отсеки корабля, отделите носовую и кормовую части лайнера железными переборками. Воспитывайте у себя привычку жить в отрезке времени, отделенном от прошлого и будущего „герметическими переборками".
Разве доктор Ослер хотел сказать, что мы не должны прилагать никаких усилий для подготовки к завтрашнему дню? Нет. Отнюдь нет. Он лишь неустанно утверждал в этом выступлении, что лучший способ подготовиться к завтрашнему дню - сконцентрировать свои силы и способности на наилучшем выполнении сегодняшних дел."
-- "Как перестать беспокоиться и начать жить." / Дейл Карнеги, Перевод с английского З. П. Вольской.
👍8❤🔥1❤1🔥1