🫖 Я чайник! Я чайник! - таинственный код ответа HTTP 418
Вы почти никогда не увидите этот код в ответах настоящих серверов.
Но он существует! А история его появления - это чистый технический фан.
Как чайник попал в стандарт
1 апреля 1998 года вышел RFC 2324 — документ о протоколе управления кофейниками (HTCPCP). Шутка от IETF. Согласно ему, если попытаться заварить кофе в чайнике, тот должен ответить: 418 I'm a teapot — потому что он чайник, а не кофеварка.
В 2014 году появился RFC 7168 — обновление этого протокола. Чайник устоял.
Почему это не просто шутка?
Хотя RFC 2324 был явной шуткой, код 418 получил неожиданное признание:
- Многие серверы и библиотеки действительно реализовали его
- Google Chrome какое-то время показывал Easter egg при получении этого кода
- Некоторые разработчики используют его для тестирования или в качестве пасхалки
На StackOverflow разработчики делятся живыми кейсами применения:
1_ Маршрутизация через nginx
Один инженер настроил reverse proxy так: первый сервер (для неаутентифицированных) при обнаружении токена отвечает 418, и nginx автоматически перенаправляет запрос второму серверу (для аутентифицированных). Как в оригинальном протоколе: «Я чайник. Иди к кофеварке» — только кофеварка здесь второй бэкенд.
2_ Интеграционные тесты
При тестировании микросервисов через Wiremock 418 ставят дефолтным ответом на непромапленные запросы. Если тест ожидает 404 — он получит именно 404 (специально настроенный мок). А если получает 418 — значит, забыли настроить мок, и тест упал корректно, а не прошёл с ложноположительным результатом.
3_ Отладка фронтенда
В одном проекте 418 означает: «Этот запрос фронтенд никогда не должен отправлять». Такие ответы триггерят ворнинги в системе мониторинга, в отличие от обычных 400 — помогает ловить баги в логике клиента.
4_ Защита от атак
Ещё один разработчик возвращает 418 забаненным IP ещё до установки TLS-соединения — как ироничный «последний ответ» перед закрытием сокета.
🔖 А какие необычные или креативные использования HTTP-кодов видели вы? Может, кто-то использует 418 как пасхалку, или 429 для лимитов с человеческим лицом? Делитесь в комментариях — соберём коллекцию инженерного фольклора! 🚀
P.S. Код 418 официально зарезервирован и никуда не денется — мем победил бюрократию.
#fun #история #http #мем
Вы почти никогда не увидите этот код в ответах настоящих серверов.
Но он существует! А история его появления - это чистый технический фан.
Как чайник попал в стандарт
1 апреля 1998 года вышел RFC 2324 — документ о протоколе управления кофейниками (HTCPCP). Шутка от IETF. Согласно ему, если попытаться заварить кофе в чайнике, тот должен ответить: 418 I'm a teapot — потому что он чайник, а не кофеварка.
В 2014 году появился RFC 7168 — обновление этого протокола. Чайник устоял.
Почему это не просто шутка?
Хотя RFC 2324 был явной шуткой, код 418 получил неожиданное признание:
- Многие серверы и библиотеки действительно реализовали его
- Google Chrome какое-то время показывал Easter egg при получении этого кода
- Некоторые разработчики используют его для тестирования или в качестве пасхалки
На StackOverflow разработчики делятся живыми кейсами применения:
1_ Маршрутизация через nginx
Один инженер настроил reverse proxy так: первый сервер (для неаутентифицированных) при обнаружении токена отвечает 418, и nginx автоматически перенаправляет запрос второму серверу (для аутентифицированных). Как в оригинальном протоколе: «Я чайник. Иди к кофеварке» — только кофеварка здесь второй бэкенд.
2_ Интеграционные тесты
При тестировании микросервисов через Wiremock 418 ставят дефолтным ответом на непромапленные запросы. Если тест ожидает 404 — он получит именно 404 (специально настроенный мок). А если получает 418 — значит, забыли настроить мок, и тест упал корректно, а не прошёл с ложноположительным результатом.
3_ Отладка фронтенда
В одном проекте 418 означает: «Этот запрос фронтенд никогда не должен отправлять». Такие ответы триггерят ворнинги в системе мониторинга, в отличие от обычных 400 — помогает ловить баги в логике клиента.
4_ Защита от атак
Ещё один разработчик возвращает 418 забаненным IP ещё до установки TLS-соединения — как ироничный «последний ответ» перед закрытием сокета.
🔖 А какие необычные или креативные использования HTTP-кодов видели вы? Может, кто-то использует 418 как пасхалку, или 429 для лимитов с человеческим лицом? Делитесь в комментариях — соберём коллекцию инженерного фольклора! 🚀
P.S. Код 418 официально зарезервирован и никуда не денется — мем победил бюрократию.
#fun #история #http #мем
Stack Overflow
Is 418 "I'm a teapot" really an HTTP response code?
Is 418 "I'm a teapot" really an HTTP response code?
There are various references to this on the internet, including in lists of response codes, but I can't figure out whether it's a weird joke.
There are various references to this on the internet, including in lists of response codes, but I can't figure out whether it's a weird joke.
❤6
Завтра начинается DevOpsConf 2026 в Москве. В этом году все иначе: и концепция, и место проведения, и даже я чувствую себя иначе.
1. Концепция сместилась в сторону практики
2 Место проведения вместо Сколково – ВДНХ!
3. Я не только выступаю с докладом, но и смотрю впервые на результаты своей работы, как куратор от программного коммитета. Будут две активности: воркшоп по работе с инцидентами, доклад о важности UX в повседневной работе. Желаю ребятам успеха.
Будет интересно узнать, что в итоге у нас получится после всех изменений.
Приходите:
- 3 апреля 14:40 Зал 6, мой доклад "Как SLO водят вас за нос"
- 16:40 Зал 6, Круглый стол со мной "Сервис недоступен, или..."
1. Концепция сместилась в сторону практики
2 Место проведения вместо Сколково – ВДНХ!
3. Я не только выступаю с докладом, но и смотрю впервые на результаты своей работы, как куратор от программного коммитета. Будут две активности: воркшоп по работе с инцидентами, доклад о важности UX в повседневной работе. Желаю ребятам успеха.
Будет интересно узнать, что в итоге у нас получится после всех изменений.
Приходите:
- 3 апреля 14:40 Зал 6, мой доклад "Как SLO водят вас за нос"
- 16:40 Зал 6, Круглый стол со мной "Сервис недоступен, или..."
👍3❤1
2 апреля 2026 – DevOpsConf 2026 начался. Сегодня с ребятами на круглом столе обсуждали инцидент-менеджмент, кто как его строит в компаниях, как с этим жить.
Получилось живо и зал был вовлечен, да так что мы после еще час в коридоре продолжали с некоторыми слушателям обсуждать 🗣️
Узнал от коллег про опыт использования Ai-для написания хронологии инцидента, кто как разделяет и как процесс сопровождения идет.
Интересно что в итоге большинство приходит к пониманию, что есть инциденты которые могут и будут повторятся, а чинить капитально их слишком дорого, потому приходит процесс управления проблемами в помощь. Это такой процесс, что вы в карточку проблемы привязываете инциденты и их повторы, естественно есть на такие обходной путь, что вв применяете, а если в проблеме инцидентов перевалило за критическую массу, или частота стала слишком высокой - тогда возвращаемся к этой проблеме уже серьёзно и пытаемся найти решение.
#инцидент_менеджмент #sre #devopsconf #круглый_стол #конференция
Получилось живо и зал был вовлечен, да так что мы после еще час в коридоре продолжали с некоторыми слушателям обсуждать 🗣️
Узнал от коллег про опыт использования Ai-для написания хронологии инцидента, кто как разделяет и как процесс сопровождения идет.
Интересно что в итоге большинство приходит к пониманию, что есть инциденты которые могут и будут повторятся, а чинить капитально их слишком дорого, потому приходит процесс управления проблемами в помощь. Это такой процесс, что вы в карточку проблемы привязываете инциденты и их повторы, естественно есть на такие обходной путь, что вв применяете, а если в проблеме инцидентов перевалило за критическую массу, или частота стала слишком высокой - тогда возвращаемся к этой проблеме уже серьёзно и пытаемся найти решение.
#инцидент_менеджмент #sre #devopsconf #круглый_стол #конференция
🔥2
Выступил с докладом Как SLO водят вас за нос на #devopsconf 2026.
Уложился в 30 минут и было более 5 вопросов, я даже свои не задействовал ).
Было много знакомых людей, что приятно. Спасибо, что поддержали!
Материалы к докладу и презентацию выложил тут https://github.com/vseinstrumentiru/devopsconf2026/tree/main/slo_cheating
#доклад #презентация #slo
Уложился в 30 минут и было более 5 вопросов, я даже свои не задействовал ).
Было много знакомых людей, что приятно. Спасибо, что поддержали!
Материалы к докладу и презентацию выложил тут https://github.com/vseinstrumentiru/devopsconf2026/tree/main/slo_cheating
#доклад #презентация #slo
👍6❤🔥2🔥1
В начале года я стал членом программного коммитета одной из крупнейших в России IT-конференции – DevOpsConf.
Мне уже давно было интересно как это с "той" стороны: помогать докладам и людям расти, раскрывать идеи и доносить смыслы. Мне понравилось. Я люблю прямое общение и людей горящих своей идеей.
Двое моих кандидатов я успешно защитил перед ПК, они выступили на конференции - очень рад за ребят. В жизни они оказались такими же активными, как я их и представлял.
Встретимся в следующем году на DevOpsConf 2027.
Заявки на DevOpsConf 2027 будут принимать с ноября декабря 2026 https://cfp.devopsconf.io
Мне уже давно было интересно как это с "той" стороны: помогать докладам и людям расти, раскрывать идеи и доносить смыслы. Мне понравилось. Я люблю прямое общение и людей горящих своей идеей.
Двое моих кандидатов я успешно защитил перед ПК, они выступили на конференции - очень рад за ребят. В жизни они оказались такими же активными, как я их и представлял.
Встретимся в следующем году на DevOpsConf 2027.
Заявки на DevOpsConf 2027 будут принимать с ноября декабря 2026 https://cfp.devopsconf.io
🔥3
Появились фотки с конференции Observability Conf 2026 которая прошла 19 марта 2026.
Конференцияч прошла класпно - нас смотрело более 2000 человек онлайн только, без учета всех пришедших оффлайн!
Смотрим фотки и предлагаем темы в группе https://t.me/observability_russia
#фото #ObservabilityConf
Конференцияч прошла класпно - нас смотрело более 2000 человек онлайн только, без учета всех пришедших оффлайн!
Смотрим фотки и предлагаем темы в группе https://t.me/observability_russia
#фото #ObservabilityConf
Telegram
Observability Russia
📊🖥 Добро пожаловать в сообщество, посвященное мониторингу и observability!
📰 Новости, обмен кейсами и лучшие практики по мониторингу, observability и AIOps. Решаем задачи и двигаем тему вместе!!! 🚀
#Мониторинг #Observibility #AIOps #Наблюдаемость
📰 Новости, обмен кейсами и лучшие практики по мониторингу, observability и AIOps. Решаем задачи и двигаем тему вместе!!! 🚀
#Мониторинг #Observibility #AIOps #Наблюдаемость
#не_sre #разработка Как я сделал автоматизацию малого бизнеса
Кейс: Клиент хотел интеграцию с 1С и параметрические чертежи, но я решил реальную боль
1. Что просил клиент: сделать параметрическую генерацию чертежей и сразу интегрировать в 1С
2. Что мы нашли как реальную боль: узкое место - разработка чертежей, зависит от возможностей человека конструктора.
3. Что сделали за неделю: proof of concept - генерация чертежей и схемы резки труб на одной простой модели клиента, далее можно было добавлять другие модели, спецификации и схемы резки труб с длиной и углами реза.
Первая версия работала уже через месяц.
4. Результат (слова клиента / метрика): подготовка одного чертежа ускорилась в 12 раз, с 1ч до 5м.
5. Вывод: выделение самой главной проблемы и следование принципу Парето позволяет получить результат значительно быстрее, быстрее его скорректировать и начать получать реальную пользу.
Интеграция в 1C по итогу не понадобилась. А она бы увеличивала сложность медлительность проекта минимум до 3 месяцев!
#проекты #автоматизация_производств #наблюдения
Кейс: Клиент хотел интеграцию с 1С и параметрические чертежи, но я решил реальную боль
1. Что просил клиент: сделать параметрическую генерацию чертежей и сразу интегрировать в 1С
2. Что мы нашли как реальную боль: узкое место - разработка чертежей, зависит от возможностей человека конструктора.
3. Что сделали за неделю: proof of concept - генерация чертежей и схемы резки труб на одной простой модели клиента, далее можно было добавлять другие модели, спецификации и схемы резки труб с длиной и углами реза.
Первая версия работала уже через месяц.
4. Результат (слова клиента / метрика): подготовка одного чертежа ускорилась в 12 раз, с 1ч до 5м.
5. Вывод: выделение самой главной проблемы и следование принципу Парето позволяет получить результат значительно быстрее, быстрее его скорректировать и начать получать реальную пользу.
Интеграция в 1C по итогу не понадобилась. А она бы увеличивала сложность медлительность проекта минимум до 3 месяцев!
#проекты #автоматизация_производств #наблюдения
📊 Про важность правильной агрегации метрик
Эти картинки хорошо помогают понять, когда данные, будь они самые настоящие, могут вас ввести в заблуждение.
Разговор о среднем чем-то там довольно часто можно услышать как в жизни, так и в работе. Особенно это важно в мониторинге - неправильно настроил и мимо тебя проходит инцидент за инцидентом, а узнаешь ты из самого надежного источника - от пользователей.
Почему пользователи самый надежный источник ? Да потому что некоторые будут прямо кричать, когда не смогут забрать товар с ПВЗ, и это дойдёт к вам не быстро через службу поддержки.
Это база, которую следует помнить при настройке мониторинга.
🤔 А как у вас? "Среднее по больнице" уже делало сюрпризы?
Картинки из поста https://x.com/nalgeon/status/1358783814022156291
Эти картинки хорошо помогают понять, когда данные, будь они самые настоящие, могут вас ввести в заблуждение.
Разговор о среднем чем-то там довольно часто можно услышать как в жизни, так и в работе. Особенно это важно в мониторинге - неправильно настроил и мимо тебя проходит инцидент за инцидентом, а узнаешь ты из самого надежного источника - от пользователей.
Почему пользователи самый надежный источник ? Да потому что некоторые будут прямо кричать, когда не смогут забрать товар с ПВЗ, и это дойдёт к вам не быстро через службу поддержки.
Это база, которую следует помнить при настройке мониторинга.
🤔 А как у вас? "Среднее по больнице" уже делало сюрпризы?
Картинки из поста https://x.com/nalgeon/status/1358783814022156291
🔥5👍2❤1
Замечали, что скриншоты - это один из языком общения в поддержке и инцидентах?
Этот инструмент настолько привычный, что даже не задумываешься, что когда-то его просто не было!
Технически под капотом все прозаично. Экран - это просто массив точек в памяти. Операционная система берет состояние кадрового буфера и пишет его на диск. Ничего магического.
Интересно, что раньше это считалось инженерной функцией. Она была даже старых Nokia 15, но нельзя было просто так сохранить экран. Нужно было лезть через компьютер и специальные утилиты.
Сейчас это база в любой ОС, хоть в ПК, хоть в смартфоне.
Помню когда впервые увидел функцию распознавания текста с сриншота в MacBook - сильно обрадовался, т.к. мне тогда в 2020 приходилось часто искать проблемы в сессиях пользователей, а на скриншотах сессия была как UUID в 32 символа. Такое пока наберешь - уже задолбаешься, а еще и ошибешься, и снова задолбаешься, но уже - проверять.
А вы часто сохраняете крины ошибки для баг-репортов или предпочитаете логи?
Скриншоты логов? (для ценителей 😁)
#SRE #engineering #OS #tech_history #incident_management
Этот инструмент настолько привычный, что даже не задумываешься, что когда-то его просто не было!
Технически под капотом все прозаично. Экран - это просто массив точек в памяти. Операционная система берет состояние кадрового буфера и пишет его на диск. Ничего магического.
Интересно, что раньше это считалось инженерной функцией. Она была даже старых Nokia 15, но нельзя было просто так сохранить экран. Нужно было лезть через компьютер и специальные утилиты.
Сейчас это база в любой ОС, хоть в ПК, хоть в смартфоне.
Помню когда впервые увидел функцию распознавания текста с сриншота в MacBook - сильно обрадовался, т.к. мне тогда в 2020 приходилось часто искать проблемы в сессиях пользователей, а на скриншотах сессия была как UUID в 32 символа. Такое пока наберешь - уже задолбаешься, а еще и ошибешься, и снова задолбаешься, но уже - проверять.
А вы часто сохраняете крины ошибки для баг-репортов или предпочитаете логи?
Скриншоты логов? (для ценителей 😁)
#SRE #engineering #OS #tech_history #incident_management
AI-разработка или Vibe-кодинг. Удалось сделать продукт не трогая код руками. Что же понадобилось?
У меня как хобби осталась разработка, и иногда знакомые ко мне обращаются по этому вопросу за консультацией. Часто мы проводим 1-2 встречи, где я помогаю откопать реальную "боль" клиента, ведь только тогда можно предложить достаточно точное решение.
Так получилось и в этот раз - сначала казалось клиенту нужно построить параметрическую 3D-модель изделия, но в процессе изучения поняли, что нужен элемент визуализации, без CAD-возмодностей и строгих расчетов. Сложность проекта упала на порядок.
Ai-агентом выступал z.ai в VS Code с расширением Roo Code. Я описывал спецификации в файлах и отдавал агенту, а он писал HTML, CSS, JavaScript. Мне помогал мой опыт веб-разработки , то что я со всем этим работал и знаком, позволило мне давать правильные корректировки AI-агенту, когда он начинал делать лишнего или не так. Конечно это позволило набить руку и начать лучше применять агентов и в рабочих задачах.
Итогом стал proof of concept с одной 3D-моделью и простой логикой расчета цены за изделие.
🧙♂️ Что хочу сказать: мне очень нравится проводить клиента именно через этап от "хочу" до "ага-вот что я на самом деле хочу", это позволяет сделать более простое решение и гораздо быстрее, а значит Time-to-market будет ниже. Мне это чем то напоминает linux-философию с мелкими утилитами для решения одной проблемы. Здесь также, нам надо получить результат как можно быстрее и союкорректировать - считай истинный Agile с реальной ценностью.
#не_sre #разработка #разработка_на_заказ
У меня как хобби осталась разработка, и иногда знакомые ко мне обращаются по этому вопросу за консультацией. Часто мы проводим 1-2 встречи, где я помогаю откопать реальную "боль" клиента, ведь только тогда можно предложить достаточно точное решение.
Так получилось и в этот раз - сначала казалось клиенту нужно построить параметрическую 3D-модель изделия, но в процессе изучения поняли, что нужен элемент визуализации, без CAD-возмодностей и строгих расчетов. Сложность проекта упала на порядок.
Ai-агентом выступал z.ai в VS Code с расширением Roo Code. Я описывал спецификации в файлах и отдавал агенту, а он писал HTML, CSS, JavaScript. Мне помогал мой опыт веб-разработки , то что я со всем этим работал и знаком, позволило мне давать правильные корректировки AI-агенту, когда он начинал делать лишнего или не так. Конечно это позволило набить руку и начать лучше применять агентов и в рабочих задачах.
Итогом стал proof of concept с одной 3D-моделью и простой логикой расчета цены за изделие.
🧙♂️ Что хочу сказать: мне очень нравится проводить клиента именно через этап от "хочу" до "ага-вот что я на самом деле хочу", это позволяет сделать более простое решение и гораздо быстрее, а значит Time-to-market будет ниже. Мне это чем то напоминает linux-философию с мелкими утилитами для решения одной проблемы. Здесь также, нам надо получить результат как можно быстрее и союкорректировать - считай истинный Agile с реальной ценностью.
#не_sre #разработка #разработка_на_заказ
🧙♂️Иногда фичи рождаются из случайных артефактов
История Mortal Kombat 🥷 - отличное подтверждение.
1992 год, аркадные автоматы. В диагностическом меню MK появилась строка ERMACS - счётчик ошибок, который программист Эд Бун добавил для отладки. Игроки увидели её рядом со статистикой бойца Reptile и решили - это секретный персонаж Ermac. Пошла волна слухов, фанаты требовали добавить его. Midway могла просто убрать строчку, но в MK3 реально появился "Ermac" 🟥 в красной одежде с сильным телекинезом. Служебная метрика стала легендой франшизы.
Такое случается не только в играх. Иногда то, что мы оставляем для себя - логи, служебные надписи, отладочные данные - пользователи видят иначе и находят в этом ценность. Главное - вовремя заметить и не бояться превращать случайность в фичу.
Кстати, Эд Бун позже признался, что двусмысленность ERMACS оставили специально - чтобы подогреть интерес.
🫴 А у вас было, когда техническая деталь неожиданно становилась популярной у пользователей?
#истории #разработка
История Mortal Kombat 🥷 - отличное подтверждение.
1992 год, аркадные автоматы. В диагностическом меню MK появилась строка ERMACS - счётчик ошибок, который программист Эд Бун добавил для отладки. Игроки увидели её рядом со статистикой бойца Reptile и решили - это секретный персонаж Ermac. Пошла волна слухов, фанаты требовали добавить его. Midway могла просто убрать строчку, но в MK3 реально появился "Ermac" 🟥 в красной одежде с сильным телекинезом. Служебная метрика стала легендой франшизы.
Такое случается не только в играх. Иногда то, что мы оставляем для себя - логи, служебные надписи, отладочные данные - пользователи видят иначе и находят в этом ценность. Главное - вовремя заметить и не бояться превращать случайность в фичу.
Кстати, Эд Бун позже признался, что двусмысленность ERMACS оставили специально - чтобы подогреть интерес.
🫴 А у вас было, когда техническая деталь неожиданно становилась популярной у пользователей?
#истории #разработка
Прошлый вклад до сих пор приносит пользу
Когда-то давно я был разработчиком на Delphi и FreePascal - это были классные инструменты для наших задач. Эти языки с явным управлением памятью и поддержкой исключений (exceptions), а значит иногда можно исключение и пропустить, т.к. они могут всплывать из глубин кода, а ты мог его не ждать. Чтобы отлавливать такие для Delphi еще давно компания EurekaLog сделала unit madExcept - глобальный перехватчик необработанных исключений. Это была потрясающая находка, она давала нам возможность получать обратную связь от клиентов с деталями системы и стектрейсами.
Но для open-source решения для Lazarus IDE не было полноценного решения, потому я решил сделать нечто похожее. Попались первые наработки от энтузиастов на GitHub, которые я форкнул 9 лет назад в https://github.com/r3code/lazarus-exception-logger сейчас там 19 🌟 и 11 форков. А сегодня в него принесли обновления в PR, про который, каюсь, я не вспоминал 3 года. Представляете - его до сих пор люди используют.
Очень приятно понимать, что твоя работа приносит пользу.
🐳 А у вас бывали такие приятные сюрпризы из прошлого?
Когда-то давно я был разработчиком на Delphi и FreePascal - это были классные инструменты для наших задач. Эти языки с явным управлением памятью и поддержкой исключений (exceptions), а значит иногда можно исключение и пропустить, т.к. они могут всплывать из глубин кода, а ты мог его не ждать. Чтобы отлавливать такие для Delphi еще давно компания EurekaLog сделала unit madExcept - глобальный перехватчик необработанных исключений. Это была потрясающая находка, она давала нам возможность получать обратную связь от клиентов с деталями системы и стектрейсами.
Но для open-source решения для Lazarus IDE не было полноценного решения, потому я решил сделать нечто похожее. Попались первые наработки от энтузиастов на GitHub, которые я форкнул 9 лет назад в https://github.com/r3code/lazarus-exception-logger сейчас там 19 🌟 и 11 форков. А сегодня в него принесли обновления в PR, про который, каюсь, я не вспоминал 3 года. Представляете - его до сих пор люди используют.
Очень приятно понимать, что твоя работа приносит пользу.
🐳 А у вас бывали такие приятные сюрпризы из прошлого?
GitHub
GitHub - r3code/lazarus-exception-logger: FreePascal Exception Logger aka madExcept or EurekaLog, extended version of https://…
FreePascal Exception Logger aka madExcept or EurekaLog, extended version of https://github.com/beNative/lazarus/tree/master/components/ExceptionLogger - r3code/lazarus-exception-logger
🔥3
Когда корпоративный стиль презентаций может вам мешать на докладе
На DevOpsConf 2026 видел несколько раз красивые презентации доработанные дизайнерами. Но у всех у них был черный или сильно темный фон.
Почему это проблема видно на фото. Вы никогда заранее не знаете как в зале будет выставлен свет и как с разных углов люди будут видеть экран. Это касается экранов, когда вашу презентацию показывают не только с проектора, но и на большом мониторе.
Если у вас главный зал с монитором почти во всю ширину зала - такой проблемы не будет.
Что с этим делать? Самое простое - попросить использовать светлый вариант корп стиля, чтобы фон был белым ⬜, а шрифт основной - черным◾.
🫴 Замечали ли вы на докладах такую проблему ? Есть ли у вашей компании светлая тема?
#спикеру #презентация
На DevOpsConf 2026 видел несколько раз красивые презентации доработанные дизайнерами. Но у всех у них был черный или сильно темный фон.
Почему это проблема видно на фото. Вы никогда заранее не знаете как в зале будет выставлен свет и как с разных углов люди будут видеть экран. Это касается экранов, когда вашу презентацию показывают не только с проектора, но и на большом мониторе.
Если у вас главный зал с монитором почти во всю ширину зала - такой проблемы не будет.
Что с этим делать? Самое простое - попросить использовать светлый вариант корп стиля, чтобы фон был белым ⬜, а шрифт основной - черным◾.
🫴 Замечали ли вы на докладах такую проблему ? Есть ли у вашей компании светлая тема?
#спикеру #презентация
💯1