История технологии сегодня — 19 апреля
ℹ️ Кто родился в этот день
Андре́й Петро́вич Ершо́в (19 апреля 1931, Рубежное, Рубежанский район, Старобельский округ, УССР, Советский Союз — 8 декабря 1988, Новосибирск, Новосибирская область, Советский Союз) — советский учёный, один из пионеров теоретического и системного программирования, создатель Сибирской школы информатики, академик АН СССР (1980). Его работы оказали влияние на формирование и развитие вычислительной техники не только в СССР, но и во всём мире.
Фредери́к Фи́ллипс Брукс-младший (англ. Frederick Phillips Brooks, Jr.; 19 апреля 1931, Дарем, Северная Каролина — 17 ноября 2022, Чапел-Хилл, Северная Каролина) — американский учёный в области теории вычислительных систем, автор книги «Мифический человеко-месяц». Управлял разработкой OS/360 в IBM. Награждён Премией Тьюринга в 1999 году.
🌐 Знаковые события
1965 — Гордоном Муром сформулирован так называемый «закон Мура», согласно которому количество транзисторов в кристалле микропроцессора удваивается каждые два года.
2021 — вертолёт НАСА Ingenuity стал первым летательным аппаратом землян, совершившим полёт на другой планете.
#Biography #Birth_Date #Events #19апреля
Андре́й Петро́вич Ершо́в (19 апреля 1931, Рубежное, Рубежанский район, Старобельский округ, УССР, Советский Союз — 8 декабря 1988, Новосибирск, Новосибирская область, Советский Союз) — советский учёный, один из пионеров теоретического и системного программирования, создатель Сибирской школы информатики, академик АН СССР (1980). Его работы оказали влияние на формирование и развитие вычислительной техники не только в СССР, но и во всём мире.
Фредери́к Фи́ллипс Брукс-младший (англ. Frederick Phillips Brooks, Jr.; 19 апреля 1931, Дарем, Северная Каролина — 17 ноября 2022, Чапел-Хилл, Северная Каролина) — американский учёный в области теории вычислительных систем, автор книги «Мифический человеко-месяц». Управлял разработкой OS/360 в IBM. Награждён Премией Тьюринга в 1999 году.
1965 — Гордоном Муром сформулирован так называемый «закон Мура», согласно которому количество транзисторов в кристалле микропроцессора удваивается каждые два года.
2021 — вертолёт НАСА Ingenuity стал первым летательным аппаратом землян, совершившим полёт на другой планете.
#Biography #Birth_Date #Events #19апреля
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2👍1
11. Fallback и graceful degradation — когда всё сломалось, но пользователь этого не заметил
Retry, Circuit Breaker, Bulkhead, Timeout — мы настроили всё, но что получает пользователь, когда внешний сервис всё равно недоступен? В лучшем случае — 500 ошибку. В худшем — тишину. Это бизнес-потеря.
В этом видео мы закрываем последний пробел — Fallback (план «Б») и graceful degradation (грациозную деградацию).
Показываем, как система должна адаптироваться к отказам, а не падать вместе с зависимостями.
На примере OrderHub (Spring Boot + Resilience4j):
почему 500 ошибка — это не вариант, когда речь идёт о бизнесе;
как переработать существующие fallback-методы — от «бросить исключение» до «спасти заказ»;
локальная очередь на примере статуса PENDING;
шедулер для повторной обработки отложенных платежей;
Исходный код проекта на GitHub очень ждет Ваших звезд☺️ (Вам че блин, жалко?)
Ссылка на Youtube
Ссылка на Рутьюб
Смотрите, ставьте лайки, подписывайтесь на каналы!✌️
❗️ ❗️ ❗️ Огромная просьба - если Вам понравилась моя работа, распространите эту серию по всем доступным вам местам: телеграм, discord и прочим каналам. ❗️ ❗️ ❗️
Буду крайне благодарен🙂
Retry, Circuit Breaker, Bulkhead, Timeout — мы настроили всё, но что получает пользователь, когда внешний сервис всё равно недоступен? В лучшем случае — 500 ошибку. В худшем — тишину. Это бизнес-потеря.
В этом видео мы закрываем последний пробел — Fallback (план «Б») и graceful degradation (грациозную деградацию).
Показываем, как система должна адаптироваться к отказам, а не падать вместе с зависимостями.
На примере OrderHub (Spring Boot + Resilience4j):
почему 500 ошибка — это не вариант, когда речь идёт о бизнесе;
как переработать существующие fallback-методы — от «бросить исключение» до «спасти заказ»;
локальная очередь на примере статуса PENDING;
шедулер для повторной обработки отложенных платежей;
Исходный код проекта на GitHub очень ждет Ваших звезд
Ссылка на Youtube
Ссылка на Рутьюб
Смотрите, ставьте лайки, подписывайтесь на каналы!
Буду крайне благодарен
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7🔥3
Java for Beginner
11. Fallback и graceful degradation — когда всё сломалось, но пользователь этого не заметил Retry, Circuit Breaker, Bulkhead, Timeout — мы настроили всё, но что получает пользователь, когда внешний сервис всё равно недоступен? В лучшем случае — 500 ошибку.…
Кто посмотрел?🧑💻
Дайте обратную связь? Что хорошо, какие моменты плохо?
Может что-то поменять?🤓
Заранее спасибо🕊
Дайте обратную связь? Что хорошо, какие моменты плохо?
Может что-то поменять?
Заранее спасибо
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
История технологии сегодня — 20 апреля
ℹ️ Кто родился в этот день
Юрий Павлович Семёнов (род. 20 апреля 1935 года, Торопец, Калининская область) — советский и российский конструктор космической техники, педагог, профессор. Генеральный конструктор НПО «Энергия» (1989—2005).
Карл Алекса́ндр Мю́ллер (нем. Karl Alexander Müller; 20 апреля 1927, Базель — 9 января 2023, Цюрих) — швейцарский физик, лауреат Нобелевской премии по физике в 1987 году, совместно с Георгом Беднорцем, «за важный прорыв в физике, выразившийся в открытии сверхпроводимости в керамических материалах».
🌐 Знаковые события
1902 — супруги Мария и Пьер Кюри получили чистый радий.
1940 — В США продемонстрирован первый электронный микроскоп.
1972 — прилуняется пилотируемый космический корабль «Аполлон-16».
1998 — Фирма Intel анонсировала процессор Pentium II Xeon.
#Biography #Birth_Date #Events #20апреля
Юрий Павлович Семёнов (род. 20 апреля 1935 года, Торопец, Калининская область) — советский и российский конструктор космической техники, педагог, профессор. Генеральный конструктор НПО «Энергия» (1989—2005).
Карл Алекса́ндр Мю́ллер (нем. Karl Alexander Müller; 20 апреля 1927, Базель — 9 января 2023, Цюрих) — швейцарский физик, лауреат Нобелевской премии по физике в 1987 году, совместно с Георгом Беднорцем, «за важный прорыв в физике, выразившийся в открытии сверхпроводимости в керамических материалах».
1902 — супруги Мария и Пьер Кюри получили чистый радий.
1940 — В США продемонстрирован первый электронный микроскоп.
1972 — прилуняется пилотируемый космический корабль «Аполлон-16».
1998 — Фирма Intel анонсировала процессор Pentium II Xeon.
#Biography #Birth_Date #Events #20апреля
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Раздел 9. Исключения, логирование, отладка
Глава 1. Иерархия исключений (Exceptions)
throws в сигнатуре метода – проброс исключений наверх. Когда это оправдано
Ключевое слово throws в сигнатуре метода Java формирует явный контракт между реализацией и вызывающим кодом. Оно объявляет, что метод может завершиться не нормально, выбросив одно из перечисленных checked-исключений, и перекладывает обязанность обработки на вызывающую сторону. Это часть системы проверяемых исключений Java, где компилятор гарантирует, что каждый potential failure path либо обработан локально, либо явно проброшен дальше по стеку вызовов.
Сигнатура с throws создает сильную связанность (tight coupling) между уровнями абстракции. Когда метод объявляет throws IOException, он экспонирует деталь реализации — использование ввода-вывода — в публичный API. Это называется утечкой абстракции (abstraction leak), когда низкоуровневые детали просачиваются через интерфейсы высокоуровневых компонентов. Вызов такого метода вынуждает все вызывающие методы также объявлять IOException в своих сигнатурах, создавая каскадную зависимость, которая распространяется от инфраструктурного слоя до пользовательского интерфейса.
Когда проброс оправдан: сценарии восстановления
Объявление исключений в сигнатуре методologically оправдано только в ограниченном наборе сценариев.
Первичный критерий — возможность и вероятность восстановления от ошибки на уровне вызывающего кода. Если исключение представляет собой ожидаемое, восстановимое условие, и вызывающий код может принять осмысленное альтернативное действие, тогда throws уместен.
Пример восстановимого сценария — бизнес-исключение InsufficientFundsException в платежной системе. Вызывающий код (координатор транзакции) может перехватить это исключение и предпринять альтернативные действия: предложить пользователю другой способ оплаты, разбить платеж на части, или отложить операцию. В этом случае checked-исключение с throws в сигнатуре метода processPayment форсирует явную обработку критичного бизнес-сценария.
Другой допустимый случай — низкоуровневые API, где пользователь должен осознанно принять решение об обработке ресурсов. Например, конструктор FileInputStream объявляет throws FileNotFoundException, потому что отсутствие файла — это условие, которое вызывающий код может предвидеть и обработать (создать файл, запросить альтернативный путь, продолжить без файла).
Однако современная практика свидетельствует о том, что даже в этих сценариях часто предпочтительны unchecked-исключения с документированием через @throws в Javadoc, а не checked-исключения с throws в сигнатуре.
Exception Translation: оборачивание vs проброс
В многослойной архитектуре прямой проброс низкоуровневых исключений наверх считается антипаттерном. Вместо этого применяется паттерн Exception Translation — перехват низкоуровневого исключения и оборачивание его в высокоуровневое, соответствующее абстракции текущего слоя.
Рассмотрим типичный сценарий с доступом к данным:
В этом примере DataAccessException — unchecked-исключение из Spring Framework, которое скрывает детали SQL, но сохраняет оригинальную причину (cause) для отладки. Это достигает нескольких целей: инкапсуляция деталей реализации, предоставление контекстно-зависимого сообщения об ошибке, и поддержание чистоты сигнатур методов бизнес-логики.
#Java #для_новичков #beginner #exception #throws
Глава 1. Иерархия исключений (Exceptions)
throws в сигнатуре метода – проброс исключений наверх. Когда это оправдано
Ключевое слово throws в сигнатуре метода Java формирует явный контракт между реализацией и вызывающим кодом. Оно объявляет, что метод может завершиться не нормально, выбросив одно из перечисленных checked-исключений, и перекладывает обязанность обработки на вызывающую сторону. Это часть системы проверяемых исключений Java, где компилятор гарантирует, что каждый potential failure path либо обработан локально, либо явно проброшен дальше по стеку вызовов.
Сигнатура с throws создает сильную связанность (tight coupling) между уровнями абстракции. Когда метод объявляет throws IOException, он экспонирует деталь реализации — использование ввода-вывода — в публичный API. Это называется утечкой абстракции (abstraction leak), когда низкоуровневые детали просачиваются через интерфейсы высокоуровневых компонентов. Вызов такого метода вынуждает все вызывающие методы также объявлять IOException в своих сигнатурах, создавая каскадную зависимость, которая распространяется от инфраструктурного слоя до пользовательского интерфейса.
Когда проброс оправдан: сценарии восстановления
Объявление исключений в сигнатуре методologically оправдано только в ограниченном наборе сценариев.
Первичный критерий — возможность и вероятность восстановления от ошибки на уровне вызывающего кода. Если исключение представляет собой ожидаемое, восстановимое условие, и вызывающий код может принять осмысленное альтернативное действие, тогда throws уместен.
Пример восстановимого сценария — бизнес-исключение InsufficientFundsException в платежной системе. Вызывающий код (координатор транзакции) может перехватить это исключение и предпринять альтернативные действия: предложить пользователю другой способ оплаты, разбить платеж на части, или отложить операцию. В этом случае checked-исключение с throws в сигнатуре метода processPayment форсирует явную обработку критичного бизнес-сценария.
Другой допустимый случай — низкоуровневые API, где пользователь должен осознанно принять решение об обработке ресурсов. Например, конструктор FileInputStream объявляет throws FileNotFoundException, потому что отсутствие файла — это условие, которое вызывающий код может предвидеть и обработать (создать файл, запросить альтернативный путь, продолжить без файла).
Однако современная практика свидетельствует о том, что даже в этих сценариях часто предпочтительны unchecked-исключения с документированием через @throws в Javadoc, а не checked-исключения с throws в сигнатуре.
Exception Translation: оборачивание vs проброс
В многослойной архитектуре прямой проброс низкоуровневых исключений наверх считается антипаттерном. Вместо этого применяется паттерн Exception Translation — перехват низкоуровневого исключения и оборачивание его в высокоуровневое, соответствующее абстракции текущего слоя.
Рассмотрим типичный сценарий с доступом к данным:
// Антипаттерн: прямая передача SQLException через все слои
public User findUser(String id) throws SQLException { // Нарушение абстракции
return database.query("SELECT * FROM users WHERE id = ?", id);
}
// Паттерн Exception Translation: оборачивание в доменное исключение
public User findUser(String id) {
try {
return database.query("SELECT * FROM users WHERE id = ?", id);
} catch (SQLException e) {
throw new DataAccessException("Failed to load user: " + id, e);
}
}
В этом примере DataAccessException — unchecked-исключение из Spring Framework, которое скрывает детали SQL, но сохраняет оригинальную причину (cause) для отладки. Это достигает нескольких целей: инкапсуляция деталей реализации, предоставление контекстно-зависимого сообщения об ошибке, и поддержание чистоты сигнатур методов бизнес-логики.
#Java #для_новичков #beginner #exception #throws
👍4
Важное различие между rethrow (повторным выбросом) и wrap (оборачиванием):
Rethrow — повторный выброс того же исключения без изменения типа, обычно после выполнения некоторых действий (логирование, откат транзакции):
Wrap — оборачивание исключения в новый тип, более подходящий для абстракции, с сохранением оригинальной причины:
При wrap критически важно передавать оригинальное исключение в конструктор нового исключения как cause. Это сохраняет полный стектрейс и позволяет при отладке проследить цепочку ошибок от высокоуровневого бизнес-сбоя до низкоуровневой технической причины.
Проблема интерфейсов и полиморфизма
Checked-исключения создают особые сложности при проектировании интерфейсов. Метод интерфейса, объявляющий throws CheckedException, обязывает все реализации работать с этим типом ошибки, даже если конкретная реализация не способна выбросить такое исключение.
Это нарушает принцип подстановки Лисков и создает искусственные ограничения для реализаций. Современный подход — использование unchecked-исключений в интерфейсах с документированием возможных сбоев через Javadoc, что позволяет реализациям самостоятельно решать, какие исключения выбрасывать, не нарушая контракт интерфейса.
Несовместимость с функциональным стилем
Java 8 ввела лямбда-выражения и Stream API, которые несовместимы с checked-исключениями. Функциональные интерфейсы (Function<T,R>, Consumer<T>, Supplier<T>) не объявляют checked-исключений в своих абстрактных методах, что делает невозможным прямое использование методов с throws в лямбдах.
Это архитектурное ограничение Java 8 фактически сигнализировало о том, что checked-исключения являются устаревшей концепцией для современного Java. Разработчики вынуждены прибегать к оборачиванию checked-исключений в RuntimeException внутри лямбд, что разрушает систему типов и делает checked-исключения бесполезными.
#Java #для_новичков #beginner #exception #throws
Rethrow — повторный выброс того же исключения без изменения типа, обычно после выполнения некоторых действий (логирование, откат транзакции):
public void processOrder(Order order) throws OrderValidationException {
try {
validate(order);
} catch (OrderValidationException e) {
auditLog.recordValidationFailure(order.getId(), e);
throw e; // Тот же тип, тот же стектрейс
}
}Wrap — оборачивание исключения в новый тип, более подходящий для абстракции, с сохранением оригинальной причины:
public Configuration loadConfiguration() {
try {
return parser.parse(configFile);
} catch (IOException e) {
throw new ConfigurationLoadException("Cannot read config from " + configFile, e);
}
}При wrap критически важно передавать оригинальное исключение в конструктор нового исключения как cause. Это сохраняет полный стектрейс и позволяет при отладке проследить цепочку ошибок от высокоуровневого бизнес-сбоя до низкоуровневой технической причины.
Проблема интерфейсов и полиморфизма
Checked-исключения создают особые сложности при проектировании интерфейсов. Метод интерфейса, объявляющий throws CheckedException, обязывает все реализации работать с этим типом ошибки, даже если конкретная реализация не способна выбросить такое исключение.
// Интерфейс объявляет checked-исключение
interface DataStore {
String read(String key) throws IOException;
}
// Реализация на основе памяти не может выбросить IOException,
// но вынуждена объявлять его или оборачивать в RuntimeException
class InMemoryStore implements DataStore {
@Override
public String read(String key) throws IOException { // Нелогично
return memoryMap.get(key);
}
}
Это нарушает принцип подстановки Лисков и создает искусственные ограничения для реализаций. Современный подход — использование unchecked-исключений в интерфейсах с документированием возможных сбоев через Javadoc, что позволяет реализациям самостоятельно решать, какие исключения выбрасывать, не нарушая контракт интерфейса.
Несовместимость с функциональным стилем
Java 8 ввела лямбда-выражения и Stream API, которые несовместимы с checked-исключениями. Функциональные интерфейсы (Function<T,R>, Consumer<T>, Supplier<T>) не объявляют checked-исключений в своих абстрактных методах, что делает невозможным прямое использование методов с throws в лямбдах.
// Метод с checked-исключением не может быть использован как лямбда
public String fetchUrl(String url) throws IOException {
return httpClient.get(url);
}
// Ошибка компиляции: IOException не обработано
List<String> results = urls.stream()
.map(this::fetchUrl) // Не компилируется
.collect(Collectors.toList());
Это архитектурное ограничение Java 8 фактически сигнализировало о том, что checked-исключения являются устаревшей концепцией для современного Java. Разработчики вынуждены прибегать к оборачиванию checked-исключений в RuntimeException внутри лямбд, что разрушает систему типов и делает checked-исключения бесполезными.
#Java #для_новичков #beginner #exception #throws
👍3
Современная философия: minimal throws
Современные best practices в Java-разработке рекомендуют минимальное использование throws в сигнатурах методов.
Основные принципы:
Unchecked by default: Используйте unchecked-исключения для большинства сценариев, документируя их через @throws в Javadoc.
Exception Translation на границах слоев: Перехватывайте низкоуровневые checked-исключения (SQL, IO) и оборачивайте их в высокоуровневые unchecked на границе инфраструктурного слоя.
Централизованная обработка: Используйте глобальные обработчики исключений (например, @ControllerAdvice в Spring) для преобразования исключений в HTTP-ответы или сообщения пользователю, вместо распределенной обработки через throws.
Не декларируйте unchecked: Хотя синтаксически возможно объявлять throws RuntimeException, это считается плохой практикой, так как не предоставляет полезной информации, но загромождает сигнатуру.
Пример современного подхода в Spring-приложении:
Документирование исключений
Когда throws используется, критически важно документировать каждое объявленное исключение в Javadoc с помощью тега @throws. Это объясняет, при каких условиях возникает исключение, и помогает вызывающему коду решить, нужно ли его обрабатывать.
Даже для unchecked-исключений современная практика рекомендует использовать @throws для документирования возможных сбоев, сохраняя при этом сигнатуры методов чистыми от throws.
#Java #для_новичков #beginner #exception #throws
Современные best practices в Java-разработке рекомендуют минимальное использование throws в сигнатурах методов.
Основные принципы:
Unchecked by default: Используйте unchecked-исключения для большинства сценариев, документируя их через @throws в Javadoc.
Exception Translation на границах слоев: Перехватывайте низкоуровневые checked-исключения (SQL, IO) и оборачивайте их в высокоуровневые unchecked на границе инфраструктурного слоя.
Централизованная обработка: Используйте глобальные обработчики исключений (например, @ControllerAdvice в Spring) для преобразования исключений в HTTP-ответы или сообщения пользователю, вместо распределенной обработки через throws.
Не декларируйте unchecked: Хотя синтаксически возможно объявлять throws RuntimeException, это считается плохой практикой, так как не предоставляет полезной информации, но загромождает сигнатуру.
Пример современного подхода в Spring-приложении:
// Сервис не объявляет throws, использует unchecked
@Service
public class OrderService {
public Order processOrder(OrderRequest request) {
validate(request); // Может выбросить ValidationException (unchecked)
try {
return orderRepository.save(request.toEntity());
} catch (DataAccessException e) { // Unchecked от Spring
throw new OrderProcessingException("Failed to save order", e);
}
}
private void validate(OrderRequest request) {
if (request.getAmount() <= 0) {
throw new ValidationException("Amount must be positive");
}
}
}
// Глобальная обработка без распространения throws через слои
@RestControllerAdvice
public class GlobalExceptionHandler {
@ExceptionHandler(ValidationException.class)
public ResponseEntity<ErrorResponse> handleValidation(ValidationException e) {
return ResponseEntity.badRequest()
.body(new ErrorResponse(e.getMessage()));
}
@ExceptionHandler(OrderProcessingException.class)
public ResponseEntity<ErrorResponse> handleProcessing(OrderProcessingException e) {
return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR)
.body(new ErrorResponse("Order processing failed"));
}
}
Документирование исключений
Когда throws используется, критически важно документировать каждое объявленное исключение в Javadoc с помощью тега @throws. Это объясняет, при каких условиях возникает исключение, и помогает вызывающему коду решить, нужно ли его обрабатывать.
/**
* Загружает конфигурацию приложения из файла.
*
* @param path путь к файлу конфигурации
* @return загруженная конфигурация
* @throws ConfigLoadException если файл не существует, недоступен для чтения,
* или содержимое не соответствует ожидаемому формату
*/
public Configuration loadConfiguration(Path path) {
// Реализация
}
Даже для unchecked-исключений современная практика рекомендует использовать @throws для документирования возможных сбоев, сохраняя при этом сигнатуры методов чистыми от throws.
#Java #для_новичков #beginner #exception #throws
👍3
Что выведет код?
#Tasks
public class Task200426 {
public static void main(String[] args) {
try {
method();
} catch (Exception e) {
System.out.println("Caught: " + e.getMessage());
}
}
static void method() throws Exception {
try {
throw new RuntimeException("Inner");
} catch (RuntimeException e) {
System.out.println("Inside catch");
throw new Exception("Outer");
}
}
}#Tasks
👍1
Как работает JIT-компилятор (Just-In-Time)? 🤓
Ответ:
JIT-компилятор — это часть JVM, которая переводит байт-код в машинный код во время выполнения для повышения производительности.
Когда метод выполняется часто (становится "горячим"), JIT компилирует его в нативный код, который выполняется напрямую процессором, а не интерпретируется.
В HotSpot JVM есть два JIT-компилятора: C1 (Client) для быстрого старта и C2 (Server) для агрессивной оптимизации в долгоиграющих приложениях. Tiered Compilation (уровневая компиляция) использует оба.
#собеседование
Ответ:
Когда метод выполняется часто (становится "горячим"), JIT компилирует его в нативный код, который выполняется напрямую процессором, а не интерпретируется.
В HotSpot JVM есть два JIT-компилятора: C1 (Client) для быстрого старта и C2 (Server) для агрессивной оптимизации в долгоиграющих приложениях. Tiered Compilation (уровневая компиляция) использует оба.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
История технологии сегодня — 21 апреля
ℹ️ Кто родился в этот день
Пе́рси Уи́льямс Бри́джмен (Бри́джман) (англ. Percy Williams Bridgman; 21 апреля 1882, Кембридж, Массачусетс — 20 августа 1961, Рэндольф[англ.], Нью-Гемпшир) — американский физик, лауреат Нобелевской премии по физике в 1946 году «за изобретение прибора, позволяющего создавать сверхвысокие давления, и за открытия, сделанные в связи с этим в физике высоких давлений».
В 1905 году он начал исследования некоторых явлений при высоких давлениях. Из-за поломки установки ему пришлось изменить её, в результате чего он изобрёл новый блок (систему двойного сжатия — компрессор, действующий внутри сосуда высокого давления), позволявший получать давления до 100 тысяч атмосфер (10 ГПа), рекордным стало достижение рубежа 400 000 атм[6]. Такие давления стали огромным достижением по сравнению с теми, которые достигались до того — 3000 атмосфер (0.3 ГПа). Также его имя известно в связи с прокладкой Бриджмена (выполненная из резины или мягкого металла, сжатая под давлением, большим, чем в перекрытом ею сосуде с газом, она автоматически уплотнялась при возрастании давления и не давала течи) и термодинамическим уравнением Бриджмена.
🌐 Знаковые события
1964 — при неудачной попытке запуска американского навигационного спутника «Транзит-5В» с ядерной энергетической установкой SNAP-9A на борту, находившиеся в ней 950 граммов плутония-238 рассеялись в земной атмосфере, вызвав существенное повышение естественного радиационного фона.
2005 — Компания AMD начала поставки двухъядерных процессоров Opteron.
#Biography #Birth_Date #Events #21апреля
Пе́рси Уи́льямс Бри́джмен (Бри́джман) (англ. Percy Williams Bridgman; 21 апреля 1882, Кембридж, Массачусетс — 20 августа 1961, Рэндольф[англ.], Нью-Гемпшир) — американский физик, лауреат Нобелевской премии по физике в 1946 году «за изобретение прибора, позволяющего создавать сверхвысокие давления, и за открытия, сделанные в связи с этим в физике высоких давлений».
В 1905 году он начал исследования некоторых явлений при высоких давлениях. Из-за поломки установки ему пришлось изменить её, в результате чего он изобрёл новый блок (систему двойного сжатия — компрессор, действующий внутри сосуда высокого давления), позволявший получать давления до 100 тысяч атмосфер (10 ГПа), рекордным стало достижение рубежа 400 000 атм[6]. Такие давления стали огромным достижением по сравнению с теми, которые достигались до того — 3000 атмосфер (0.3 ГПа). Также его имя известно в связи с прокладкой Бриджмена (выполненная из резины или мягкого металла, сжатая под давлением, большим, чем в перекрытом ею сосуде с газом, она автоматически уплотнялась при возрастании давления и не давала течи) и термодинамическим уравнением Бриджмена.
1964 — при неудачной попытке запуска американского навигационного спутника «Транзит-5В» с ядерной энергетической установкой SNAP-9A на борту, находившиеся в ней 950 граммов плутония-238 рассеялись в земной атмосфере, вызвав существенное повышение естественного радиационного фона.
2005 — Компания AMD начала поставки двухъядерных процессоров Opteron.
#Biography #Birth_Date #Events #21апреля
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
[Совет по Java #028]
Тема: static-методы не переопределяются.
Проблема: Статические методы принадлежат классу, а не экземпляру. Они не участвуют в полиморфизме времени выполнения (динамическом связывании).
Выбор вызываемого статического метода определяется на этапе компиляции по типу ссылки, а не по фактическому типу объекта. Это приводит к неожиданному поведению: при вызове статического метода через ссылку на родительский класс, который указывает на объект дочернего класса, будет выполнен метод родителя, даже если в дочернем классе объявлен метод с такой же сигнатурой.
Такая ситуация называется сокрытие (hiding), а не переопределение (overriding). Разработчики, привыкшие к полиморфизму экземплярных методов, часто делают ошибку, полагая, что статические методы ведут себя аналогично.
Решение: Никогда не вызывайте статические методы через объекты или ссылки. Всегда вызывайте их через имя класса: Parent.staticMethod(). Если вам нужно разное поведение в иерархии, используйте экземплярные методы или паттерн Стратегия.
Предупреждайте коллег в команде о том, что статические методы не переопределяются. Для ясности кода помечайте статические методы как static и избегайте вызова через переменные.
Объяснение: При компиляции вызова p.print() компилятор заменяет его на Parent.print(), так как тип переменной p — Parent.
Информация о фактическом типе объекта (Child) не используется для разрешения статического метода. Сокрытие (hiding) означает, что в классе-наследнике объявлен свой статический метод, но он никак не связан с методом родителя. Более того, статический метод можно вызвать даже на null-ссылке, если тип известен компилятору.
Это еще раз подчеркивает, что статические методы связаны с классом, а не с объектом.
#Java #советы
Тема: static-методы не переопределяются.
Проблема: Статические методы принадлежат классу, а не экземпляру. Они не участвуют в полиморфизме времени выполнения (динамическом связывании).
Выбор вызываемого статического метода определяется на этапе компиляции по типу ссылки, а не по фактическому типу объекта. Это приводит к неожиданному поведению: при вызове статического метода через ссылку на родительский класс, который указывает на объект дочернего класса, будет выполнен метод родителя, даже если в дочернем классе объявлен метод с такой же сигнатурой.
Такая ситуация называется сокрытие (hiding), а не переопределение (overriding). Разработчики, привыкшие к полиморфизму экземплярных методов, часто делают ошибку, полагая, что статические методы ведут себя аналогично.
Решение: Никогда не вызывайте статические методы через объекты или ссылки. Всегда вызывайте их через имя класса: Parent.staticMethod(). Если вам нужно разное поведение в иерархии, используйте экземплярные методы или паттерн Стратегия.
Предупреждайте коллег в команде о том, что статические методы не переопределяются. Для ясности кода помечайте статические методы как static и избегайте вызова через переменные.
public class StaticOverrideExample {
static class Parent {
public static void print() {
System.out.println("Parent static method");
}
public void instanceMethod() {
System.out.println("Parent instance method");
}
}
static class Child extends Parent {
// Это не переопределение, а сокрытие (hiding)
public static void print() {
System.out.println("Child static method");
}
@Override // А это корректное переопределение
public void instanceMethod() {
System.out.println("Child instance method");
}
}
public static void main(String[] args) {
Parent p = new Child();
//Антипаттерн: вызов статического метода через переменную
p.print(); // Вывод: "Parent static method" — неожиданно!
// Компилятор смотрит на тип переменной Parent, а не на объект Child
//Правильно: вызов через класс
Parent.print(); // Parent static method
Child.print(); // Child static method
// Для сравнения: экземплярный метод ведет себя полиморфно
p.instanceMethod(); // Вывод: "Child instance method" — ожидаемо
// Демонстрация опасности
Parent nullRef = null;
nullRef.print(); // Работает! (тип известен на этапе компиляции)
// nullRef.instanceMethod(); // NullPointerException
}
}Объяснение: При компиляции вызова p.print() компилятор заменяет его на Parent.print(), так как тип переменной p — Parent.
Информация о фактическом типе объекта (Child) не используется для разрешения статического метода. Сокрытие (hiding) означает, что в классе-наследнике объявлен свой статический метод, но он никак не связан с методом родителя. Более того, статический метод можно вызвать даже на null-ссылке, если тип известен компилятору.
Это еще раз подчеркивает, что статические методы связаны с классом, а не с объектом.
#Java #советы
👍4
Что выведет код?
#Tasks
class Parent210426 {
static String get() { return "Parent"; }
String nonStatic() { return "ParentNS"; }
}
class Child210426 extends Parent210426 {
static String get() { return "Child"; }
String nonStatic() { return "ChildNS"; }
}
public class Task210426 {
public static void main(String[] args) {
Parent210426 p = new Child210426();
System.out.println(p.get());
System.out.println(((Child210426) p).get());
System.out.println(p.nonStatic());
}
}#Tasks
👍2
Варианты ответа:
Anonymous Quiz
57%
Parent Child ChildNS
7%
Child Child ChildNS
14%
Parent Parent ParentNS
21%
Child Parent ChildNS
👍2
Уффф... 🥵
Я накидал неплохое такое обновление чата в devforge.ru🧑💻
Теперь в чате можно и позависать)
Жду всех там!✈️
Я накидал неплохое такое обновление чата в devforge.ru
Теперь в чате можно и позависать)
Жду всех там!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Что такое OSGi? 🤓
Ответ:
OSGi (Open Service Gateway initiative) — это модульная система и сервисная платформа для Java.
Она позволяет разбивать приложение на связанные (bundles) — динамически загружаемые модули. Каждый bundle — это JAR-файл с особой структурой MANIFEST.MF, где явно описано, какие пакеты он экспортирует (делает публичными) и какие импортирует.
OSGi обеспечивает динамическое управление жизненным циклом модулей (можно устанавливать, обновлять, останавливать модули на ходу) и строгую инкапсуляцию на уровне JAR-файлов.
#собеседование
Ответ:
Она позволяет разбивать приложение на связанные (bundles) — динамически загружаемые модули. Каждый bundle — это JAR-файл с особой структурой MANIFEST.MF, где явно описано, какие пакеты он экспортирует (делает публичными) и какие импортирует.
OSGi обеспечивает динамическое управление жизненным циклом модулей (можно устанавливать, обновлять, останавливать модули на ходу) и строгую инкапсуляцию на уровне JAR-файлов.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4
История технологии сегодня — 22 апреля
ℹ️ Кто родился в этот день
И́горь Анато́льевич Дани́лов (род. 22 апреля 1964, Ленинград) — российский программист, автор популярного антивируса Dr. Web, технический директор и основатель компании «Доктор Веб». Свой первый вирусный анализатор Игорь Данилов написал из энтузиазма в желании избавить свой НИИ от вирусных угроз. В 1992 начал разработку антивируса Dr.Web, а в 1993 году Dr.Web стал первой антивирусной программой, распознавшей и уничтожившей полиморфный вирус, что принесло ему известность в среде мировых разработчиков антивирусных средств и специалистов по борьбе с вирусами. В 2003 основал компанию «Доктор Веб».
Джу́лиус Ро́берт О́ппенге́ймер (англ. Julius Robert Oppenheimer; 22 апреля 1904, Нью-Йорк, США — 18 февраля 1967, Принстон, штат Нью-Джерси, США) — американский физик-теоретик и физик-ядерщик, широко известен как научный руководитель Манхэттенского проекта, в рамках которого в годы Второй мировой войны разрабатывались первые образцы ядерного оружия; из-за этого Оппенгеймера, наряду со Станиславом Уламом и Эдвардом Теллером часто называют «отцом атомной бомбы».
Сэмюэл Харрис Альтман (также Олтмен; англ. Samuel Harris Altman, МФА: /ˈɔːltmən/; род. 22 апреля 1985, Чикаго, Иллинойс) — американский предприниматель, инвестор, программист и блогер. С 2014 года и до увольнения в 2019-м был президентом Y Combinator, после чего стал генеральным директором OpenAI. В декабре 2025 года американский журнал Time назвал его человеком года, как одного из создателей систем искусственного интеллекта.
🌐 Знаковые события
1993 — вышла первая версия веб-браузера Mosaic.
#Biography #Birth_Date #Events #22апреля
И́горь Анато́льевич Дани́лов (род. 22 апреля 1964, Ленинград) — российский программист, автор популярного антивируса Dr. Web, технический директор и основатель компании «Доктор Веб». Свой первый вирусный анализатор Игорь Данилов написал из энтузиазма в желании избавить свой НИИ от вирусных угроз. В 1992 начал разработку антивируса Dr.Web, а в 1993 году Dr.Web стал первой антивирусной программой, распознавшей и уничтожившей полиморфный вирус, что принесло ему известность в среде мировых разработчиков антивирусных средств и специалистов по борьбе с вирусами. В 2003 основал компанию «Доктор Веб».
Джу́лиус Ро́берт О́ппенге́ймер (англ. Julius Robert Oppenheimer; 22 апреля 1904, Нью-Йорк, США — 18 февраля 1967, Принстон, штат Нью-Джерси, США) — американский физик-теоретик и физик-ядерщик, широко известен как научный руководитель Манхэттенского проекта, в рамках которого в годы Второй мировой войны разрабатывались первые образцы ядерного оружия; из-за этого Оппенгеймера, наряду со Станиславом Уламом и Эдвардом Теллером часто называют «отцом атомной бомбы».
Сэмюэл Харрис Альтман (также Олтмен; англ. Samuel Harris Altman, МФА: /ˈɔːltmən/; род. 22 апреля 1985, Чикаго, Иллинойс) — американский предприниматель, инвестор, программист и блогер. С 2014 года и до увольнения в 2019-м был президентом Y Combinator, после чего стал генеральным директором OpenAI. В декабре 2025 года американский журнал Time назвал его человеком года, как одного из создателей систем искусственного интеллекта.
1993 — вышла первая версия веб-браузера Mosaic.
#Biography #Birth_Date #Events #22апреля
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
This media is not supported in your browser
VIEW IN TELEGRAM
Хорошая новость! 💃
Devforge.ru переехал на новый более мощный сервер!✈️
RAM 4 ГБ
vCPU 2
Так что есть где развернуться...
А самое главное минимум расходов🤫
Devforge.ru переехал на новый более мощный сервер!
RAM 4 ГБ
vCPU 2
Так что есть где развернуться...
А самое главное минимум расходов
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3🔥1
Раздел 9. Исключения, логирование, отладка
Глава 1. Иерархия исключений (Exceptions)
Создание своих исключений: наследование от Exception или RuntimeException. Когда кастомное исключение оправдано
Стандартные исключения Java — IOException, IllegalArgumentException, NullPointerException — описывают универсальные классы ошибок. Однако когда приложение вырастает за пределы учебных примеров, универсальные типы перестают адекватно передавать семантику сбоев. IOException не объясняет, что именно пошло не так в бизнес-процессе обработки платежа. IllegalArgumentException не указывает, какое поле запроса нарушило правило валидации.
Кастомное исключение — это класс, расширяющий Exception или RuntimeException, который несет доменную семантику ошибки. Его название становится частью языка предметной области (ubiquitous language в терминологии Domain-Driven Design), позволяя коду самодокументироваться и облегчая обработку ошибок через специфичные catch-блоки.
Однако создание кастомных исключений — это не бесплатная операция. Каждый новый класс исключения увеличивает сложность системы, требует поддержки и тестирования. Поэтому первый вопрос, который должен задать разработчик: действительно ли стандартное исключение не передает нужную семантику?
Когда кастомное исключение оправдано
Создание собственного класса исключения оправдано в следующих сценариях:
— Доменная специфика ошибки. Когда ошибка является неотъемлемой частью бизнес-логики и требует специфической обработки. InsufficientFundsException в банковской системе или SeatUnavailableException в системе бронирования — это не технические сбои, а валидные бизнес-сценарии, которые код должен обрабатыать осмысленно.
— Необходимость дополнительного контекста. Когда стандартное исключение не позволяет передать структурированную информацию об ошибке. Кастомный класс может содержать поля для error code, идентификатора сущности, деталей валидации, которые необходимы для формирования корректного ответа API или сообщения пользователю.
— Разделение обработки в catch-блоках. Когда разные типы ошибок требуют разной логики восстановления. Иерархия кастомных исключений позволяет использовать полиморфизм в обработке: перехватить общий тип для единообразной обработки, или специфичный для особой логики.
— API для внешнего использования. Когда код предназначен для использования как библиотека или сервис, и нужно предоставить четкий контракт возможных сбоев без экспонирования внутренних деталей реализации.
Обратные сценарии, когда кастомное исключение не нужно:
— Ошибка является стандартной программной ошибкой (null-аргумент, выход за границы) — используйте IllegalArgumentException, IndexOutOfBoundsException
— Ошибка не требует специфической обработки и обрабатывается единообразно с другими сбоями
— Сценарий покрывается существующим стандартным исключением с информативным сообщением
#Java #для_новичков #beginner #exception #custom_exception
Глава 1. Иерархия исключений (Exceptions)
Создание своих исключений: наследование от Exception или RuntimeException. Когда кастомное исключение оправдано
Стандартные исключения Java — IOException, IllegalArgumentException, NullPointerException — описывают универсальные классы ошибок. Однако когда приложение вырастает за пределы учебных примеров, универсальные типы перестают адекватно передавать семантику сбоев. IOException не объясняет, что именно пошло не так в бизнес-процессе обработки платежа. IllegalArgumentException не указывает, какое поле запроса нарушило правило валидации.
Кастомное исключение — это класс, расширяющий Exception или RuntimeException, который несет доменную семантику ошибки. Его название становится частью языка предметной области (ubiquitous language в терминологии Domain-Driven Design), позволяя коду самодокументироваться и облегчая обработку ошибок через специфичные catch-блоки.
Однако создание кастомных исключений — это не бесплатная операция. Каждый новый класс исключения увеличивает сложность системы, требует поддержки и тестирования. Поэтому первый вопрос, который должен задать разработчик: действительно ли стандартное исключение не передает нужную семантику?
Когда кастомное исключение оправдано
Создание собственного класса исключения оправдано в следующих сценариях:
— Доменная специфика ошибки. Когда ошибка является неотъемлемой частью бизнес-логики и требует специфической обработки. InsufficientFundsException в банковской системе или SeatUnavailableException в системе бронирования — это не технические сбои, а валидные бизнес-сценарии, которые код должен обрабатыать осмысленно.
— Необходимость дополнительного контекста. Когда стандартное исключение не позволяет передать структурированную информацию об ошибке. Кастомный класс может содержать поля для error code, идентификатора сущности, деталей валидации, которые необходимы для формирования корректного ответа API или сообщения пользователю.
— Разделение обработки в catch-блоках. Когда разные типы ошибок требуют разной логики восстановления. Иерархия кастомных исключений позволяет использовать полиморфизм в обработке: перехватить общий тип для единообразной обработки, или специфичный для особой логики.
— API для внешнего использования. Когда код предназначен для использования как библиотека или сервис, и нужно предоставить четкий контракт возможных сбоев без экспонирования внутренних деталей реализации.
Обратные сценарии, когда кастомное исключение не нужно:
— Ошибка является стандартной программной ошибкой (null-аргумент, выход за границы) — используйте IllegalArgumentException, IndexOutOfBoundsException
— Ошибка не требует специфической обработки и обрабатывается единообразно с другими сбоями
— Сценарий покрывается существующим стандартным исключением с информативным сообщением
#Java #для_новичков #beginner #exception #custom_exception
👍4