Спасибо за вдумчивый комментарий — вопрос действительно важный.
Вы правы: когда поток ОС блокируется на I/O, он действительно спит и не тратит CPU. Проблема не в расходе вычислительных ресурсов, а в количестве таких потоков.
ОС-поток — это дорогая вещь: для каждого нужно создать стек (обычно мегабайт), сохранить контекст, управлять переключениями, синхронизацией и т.д. Если у нас тысячи одновременных запросов, ожидающих ответ от БД или сети, то тысячи потоков ОС будут находиться в спящем состоянии, занимая память и ресурсы ядра. JVM, в свою очередь, вынуждена держать эти структуры и выполнять переключения при каждом пробуждении. Это и создает накладные расходы.
Виртуальные потоки решают не задачу "ожидания байтиков", а проблему масштабирования, то есть они позволяют иметь миллионы задач, ожидающих I/O, при этом переиспользуя ограниченное количество настоящих (carrier) потоков ОС. Планирование действительно реализовано в JVM, но оно легковесное: это просто привязка контекста задачи к системному потоку, без выделения отдельного стека в ядре.
То есть это не "костыль поверх ОС", а второй уровень планирования, можно сказать надстройка, оптимизированная под модель массовой конкурентности без активных вычислений, когда тысячи задач делают что-то простое и ждут I/O.
По сути, виртуальные потоки это не попытка обойти ОС, а инструмент, чтобы JVM могла эффективно использовать ОС-потоки там, где обычная модель 1:1 перестает масштабироваться.
Спасибо за такой развернутый комментарий! Статья ориентирована на начинающих разработчиков, поэтому мы сознательно сильно не углублялись в технические детали и нюансы.
Отдельное спасибо за ссылки и дополнения — все по делу. Моменты, которые ты выделил жирным, абсолютно точные и, по сути, хорошо резюмируют главный посыл материала.
Пока — нет. И Log4j 2, и Logback остаются ThreadLocal-based для MDC/ThreadContext. «Новое» сегодня — контекст-пропагация (напр., Reactor 3.5 + Micrometer), которая переносит и поднимает MDC на время логирования. Это уменьшает боль, но не отменяет ограничения ThreadLocal. Параллельно в сообществах Log4j/SLF4J уже идут обсуждения перехода к ScopedValue/ScopedContext, но стабильных релизов «без ThreadLocal» пока нет.
Спасибо большое за отклик — особенно ценно услышать мнение от коллеги с похожим опытом из другой области.
С джунами действительно важно удерживать баланс: мягкость помогает выстроить доверие, но если ошибки повторяются или нарушаются договоренности — я стараюсь говорить строже, но при этом сохранять открытый диалог.
Спасибо, что подсветили тему развития — очень важная и точно достойна отдельного разговора.
Спасибо за интерес к статье и нашей команде :) Можешь отправить резюме на job@naumen.ru — мы сохраним твои контакты и свяжемся, как только появится подходящая вакансия.
Спасибо за вопрос! Это была задача от заказчика по ручному анализу и очистке входящих данных в Excel. Тогда автоматизировать подобные процессы не получалось, поэтому задача относилась к зоне ответственности бизнеса — нужно было хорошо разбираться в специфике данных в их сфере. Мне же нужно было работать уже с актуальными данными.
Оба подхода обладают своими плюсами и минусами, серебряной пули, к сожалению, не существует. EAV использовался в проектном решении этой задачи, но таблица разрастается довольно быстро, и это может начать создавать проблемы производительности.
Что касается JSONB, то под капотом в случае с Postgres используется именно он — как более эффективный.
Привет! Спасибо, что высказал интересную мысль :) Мы всегда открыты к новым идеям, так что ты можешь написать нам в Telegram @naumen_connect, сможем подробнее обсудить формат, который тебе кажется перспективным.
Добрый день! Конечно, посчитать точно возможности нет, всегда есть приближенные расчеты.
Мы считаем, что повлияли именно изменения в продукте, так как «соседний» продукт для внутренней поддержки не вырос настолько же в тех же условиях рынка, когда началось импортозамещение. При этом исторически видели, что оба продукта примерно одинаково реагировали на волнения на рынке.
Я не встречал методик по определению уровня неопределенности. Существуют методы оценки риска, да. Но это другое. Суть mindmap, о котором идет речь в статье (можно посмотреть здесь: https://miro.com/app/board/uXjVNEOGewU=/), чтобы иметь инструмент для определения составляющих (аспектов), по которым мы, возможно, не учли какие-то требования. И далее, что делать, чтобы выявить и формализовать эти требования.
Проблема в статье рассматривается не с точки зрения менеджмента, а с точки зрения результативности команды. Конечно, это более актуально, когда формат договора предполагает обоюдную ответственность для заказчика и исполнителя, как, например, в fixed price & fixed scope. А еще более значимо во внутренней разработке.
Оценить рамки неопределенности как раз и помогает mindmap. Чтобы было понятнее, вот ссылка: https://miro.com/app/board/uXjVNEOGewU=/. Чем раньше с его помощью получится понять, что есть «слепые зоны», тем лучше для всех.
Если кратко, то: первое — наши хорошо отлаженные процессы позволяют проводить подобные обновления, второе — как отметил в статье, каждое обновление приносит с собой и улучшение языка, и повышение безопасности и перформанса продукта из коробки.
Клиентоориентированность — общая тенденция. Сейчас она применяется почти везде. В проектном подходе мы ориентируемся на конкретного клиента, для которого реализуем проект. А в продуктовом — на большинство клиентов, имеющих схожие потребности.
Процессный подход относится к другой категории. То есть его некорректно сравнивать или противопоставлять продуктовому подходу, о котором говорим в статье.
Когда собеседник не знает/не понимает конечную цель или не может ее сформулировать, он отвечает простыми и понятными ему вещами — рутинными действиями. Я это называю «Я работаю, чтобы делать свою работу».
Для того, чтобы копнуть глубже, использую метод «5 почему». Приведу пример из жизни, который рассказывал своим коллегам:
— Я хочу купить машину.
— Зачем?
— Чтобы ездить.
— Куда ты собираешься на ней ездить?
— Я хочу ездить на ней на работу.
— Ты можешь добираться на автобусе или на метро, это быстрее и без пробок. Для чего машина?
— Утром я хочу выезжать пораньше, чтобы успевать отвозить детей в детский сад, который находится на другом конце города. Потом добираться до офиса. После работы забирать детей из детского сада и возвращаться пораньше, чтобы успеть к ужину, который приготовила жена, после провести время с ней. А еще вспомнил, что хочу иногда ездить на базу отдыха за городом и не быть привязанным к расписанию электричек.
В этом примере мы натыкаемся на умение формулировать цель действия — покупки машины. Мы получили ответ «действие». Затем задали второй уточняющий вопрос и все равно получили ответ в виде действия. Лишь на третьем вопросе, копнув глубже, мы получили развернутый ответ и узнали те цели, которые преследует собеседник.
В проектах автоматизации мы натыкаемся на аналогичные случаи. Например, заказчик просит сделать в задаче даты планового и фактического выполнения. Его мотивация на поверхности — хочу видеть, какие сотрудники вовремя выполняют задачи. Если начать копать зачем, почему, когда — мы выясним: что он хочет каждый день видеть, какие сотрудники не укладываются в срок и по каким задачам. В ходе диалога мы понимаем, что ему нужна не просто дата, а еще и ежедневный удобный отчет. Пользователь не знал, что мы можем быстро настроить ему выгрузку, поэтому опирался на свой прошлый опыт — визуально бы сравнивал в экселе.
Решили выделить роль администратора из-за большой нагрузки на РП. В ответственность РП входит все вами перечисленное.
Мы ведем как записи встреч, если это возможно, так и протоколы, которые чаще пишут администраторы. В протоколах фиксируем, какие вопросы обсуждали и какие решения приняли. Поэтому нить проекта РП не упускает. К тому же, РП сам может зафиксировать важные для себя моменты.
Чтобы лучше понять разницу между процессным, проектным и продуктовым подходом, можно познакомиться со «стоматологической» аналогией.
Мы не оцениваем проектный и продуктовый подходы с точки зрения плохой или хороший —каждый из них применим в разных ситуациях. Для закрытия уникальной потребности лучше всего подойдет проект. А для решения типовых задач, повторяющихся у разных заказчиков, оптимален продукт
Считать ли типовые проекты продуктом? Это зависит от подхода, применяемого при реализации этих типовых проектов. Если каждый раз они выполняются «с нуля», без использования предыдущего опыта, то продуктом это назвать сложно. Если же есть типовые решения, которые применяются из раза в раз при совпадении исходных условий, то это уже ближе к продукту. А если эти типовые решения не просто применяются, но и анализируется опыт их использования, оптимизируется их функционал на основе этого анализа, то смело можем говорить о продуктовом решении.
Группа администрирования работает не только на проектах внедрения, а занимается отчетами, учетом лицензий, организацией обучения клиентов, организацией рабочего пространства для сотрудников подразделения и т.д. Также в практике два направления: продуктовое и центр внедрения. Группа администрирования работает на оба: например, тот же технический писатель занимается как проектной документацией, так и документацией для продуктов.
Если бы РП был прямым руководителем этой группы, на него легла бы дополнительная нагрузка — в виде распределения и контроля всех этих задач. Сейчас это делает Света.
Спасибо за вдумчивый комментарий — вопрос действительно важный.
Вы правы: когда поток ОС блокируется на I/O, он действительно спит и не тратит CPU. Проблема не в расходе вычислительных ресурсов, а в количестве таких потоков.
ОС-поток — это дорогая вещь: для каждого нужно создать стек (обычно мегабайт), сохранить контекст, управлять переключениями, синхронизацией и т.д. Если у нас тысячи одновременных запросов, ожидающих ответ от БД или сети, то тысячи потоков ОС будут находиться в спящем состоянии, занимая память и ресурсы ядра. JVM, в свою очередь, вынуждена держать эти структуры и выполнять переключения при каждом пробуждении. Это и создает накладные расходы.
Виртуальные потоки решают не задачу "ожидания байтиков", а проблему масштабирования, то есть они позволяют иметь миллионы задач, ожидающих I/O, при этом переиспользуя ограниченное количество настоящих (carrier) потоков ОС. Планирование действительно реализовано в JVM, но оно легковесное: это просто привязка контекста задачи к системному потоку, без выделения отдельного стека в ядре.
То есть это не "костыль поверх ОС", а второй уровень планирования, можно сказать надстройка, оптимизированная под модель массовой конкурентности без активных вычислений, когда тысячи задач делают что-то простое и ждут I/O.
По сути, виртуальные потоки это не попытка обойти ОС, а инструмент, чтобы JVM могла эффективно использовать ОС-потоки там, где обычная модель 1:1 перестает масштабироваться.
Под "полноценный поток операционной системы" подразумевается "объект Thread отображается один к одному на поток операционной системы"
Спасибо за такой развернутый комментарий! Статья ориентирована на начинающих разработчиков, поэтому мы сознательно сильно не углублялись в технические детали и нюансы.
Отдельное спасибо за ссылки и дополнения — все по делу. Моменты, которые ты выделил жирным, абсолютно точные и, по сути, хорошо резюмируют главный посыл материала.
Пока — нет. И Log4j 2, и Logback остаются ThreadLocal-based для MDC/ThreadContext. «Новое» сегодня — контекст-пропагация (напр., Reactor 3.5 + Micrometer), которая переносит и поднимает MDC на время логирования. Это уменьшает боль, но не отменяет ограничения ThreadLocal. Параллельно в сообществах Log4j/SLF4J уже идут обсуждения перехода к ScopedValue/ScopedContext, но стабильных релизов «без ThreadLocal» пока нет.
Спасибо большое за отклик — особенно ценно услышать мнение от коллеги с похожим опытом из другой области.
С джунами действительно важно удерживать баланс: мягкость помогает выстроить доверие, но если ошибки повторяются или нарушаются договоренности — я стараюсь говорить строже, но при этом сохранять открытый диалог.
Спасибо, что подсветили тему развития — очень важная и точно достойна отдельного разговора.
Спасибо за интерес к статье и нашей команде :) Можешь отправить резюме на job@naumen.ru — мы сохраним твои контакты и свяжемся, как только появится подходящая вакансия.
Спасибо за вопрос! Это была задача от заказчика по ручному анализу и очистке входящих данных в Excel. Тогда автоматизировать подобные процессы не получалось, поэтому задача относилась к зоне ответственности бизнеса — нужно было хорошо разбираться в специфике данных в их сфере. Мне же нужно было работать уже с актуальными данными.
Оба подхода обладают своими плюсами и минусами, серебряной пули, к сожалению, не существует. EAV использовался в проектном решении этой задачи, но таблица разрастается довольно быстро, и это может начать создавать проблемы производительности.
Что касается JSONB, то под капотом в случае с Postgres используется именно он — как более эффективный.
Привет! Спасибо, что высказал интересную мысль :) Мы всегда открыты к новым идеям, так что ты можешь написать нам в Telegram @naumen_connect, сможем подробнее обсудить формат, который тебе кажется перспективным.
Добрый день! Конечно, посчитать точно возможности нет, всегда есть приближенные расчеты.
Мы считаем, что повлияли именно изменения в продукте, так как «соседний» продукт для внутренней поддержки не вырос настолько же в тех же условиях рынка, когда началось импортозамещение. При этом исторически видели, что оба продукта примерно одинаково реагировали на волнения на рынке.
Я не встречал методик по определению уровня неопределенности. Существуют методы оценки риска, да. Но это другое. Суть mindmap, о котором идет речь в статье (можно посмотреть здесь: https://miro.com/app/board/uXjVNEOGewU=/), чтобы иметь инструмент для определения составляющих (аспектов), по которым мы, возможно, не учли какие-то требования. И далее, что делать, чтобы выявить и формализовать эти требования.
Проблема в статье рассматривается не с точки зрения менеджмента, а с точки зрения результативности команды. Конечно, это более актуально, когда формат договора предполагает обоюдную ответственность для заказчика и исполнителя, как, например, в fixed price & fixed scope. А еще более значимо во внутренней разработке.
Оценить рамки неопределенности как раз и помогает mindmap. Чтобы было понятнее, вот ссылка: https://miro.com/app/board/uXjVNEOGewU=/. Чем раньше с его помощью получится понять, что есть «слепые зоны», тем лучше для всех.
Да, верно, изначально в коде этой строки не было, видимо, при публикации что-то слетело. Спасибо за внимательность, поправили!
Если кратко, то: первое — наши хорошо отлаженные процессы позволяют проводить подобные обновления, второе — как отметил в статье, каждое обновление приносит с собой и улучшение языка, и повышение безопасности и перформанса продукта из коробки.
В финальной части доклада на ютубе более подробно рассказал, почему полезно обновление.
Клиентоориентированность — общая тенденция. Сейчас она применяется почти везде. В проектном подходе мы ориентируемся на конкретного клиента, для которого реализуем проект. А в продуктовом — на большинство клиентов, имеющих схожие потребности.
Процессный подход относится к другой категории. То есть его некорректно сравнивать или противопоставлять продуктовому подходу, о котором говорим в статье.
Когда собеседник не знает/не понимает конечную цель или не может ее сформулировать, он отвечает простыми и понятными ему вещами — рутинными действиями. Я это называю «Я работаю, чтобы делать свою работу».
Для того, чтобы копнуть глубже, использую метод «5 почему». Приведу пример из жизни, который рассказывал своим коллегам:
— Я хочу купить машину.
— Зачем?
— Чтобы ездить.
— Куда ты собираешься на ней ездить?
— Я хочу ездить на ней на работу.
— Ты можешь добираться на автобусе или на метро, это быстрее и без пробок. Для чего машина?
— Утром я хочу выезжать пораньше, чтобы успевать отвозить детей в детский сад, который находится на другом конце города. Потом добираться до офиса. После работы забирать детей из детского сада и возвращаться пораньше, чтобы успеть к ужину, который приготовила жена, после провести время с ней. А еще вспомнил, что хочу иногда ездить на базу отдыха за городом и не быть привязанным к расписанию электричек.
В этом примере мы натыкаемся на умение формулировать цель действия — покупки машины. Мы получили ответ «действие». Затем задали второй уточняющий вопрос и все равно получили ответ в виде действия. Лишь на третьем вопросе, копнув глубже, мы получили развернутый ответ и узнали те цели, которые преследует собеседник.
В проектах автоматизации мы натыкаемся на аналогичные случаи. Например, заказчик просит сделать в задаче даты планового и фактического выполнения. Его мотивация на поверхности — хочу видеть, какие сотрудники вовремя выполняют задачи. Если начать копать зачем, почему, когда — мы выясним: что он хочет каждый день видеть, какие сотрудники не укладываются в срок и по каким задачам. В ходе диалога мы понимаем, что ему нужна не просто дата, а еще и ежедневный удобный отчет. Пользователь не знал, что мы можем быстро настроить ему выгрузку, поэтому опирался на свой прошлый опыт — визуально бы сравнивал в экселе.
Решили выделить роль администратора из-за большой нагрузки на РП. В ответственность РП входит все вами перечисленное.
Мы ведем как записи встреч, если это возможно, так и протоколы, которые чаще пишут администраторы. В протоколах фиксируем, какие вопросы обсуждали и какие решения приняли. Поэтому нить проекта РП не упускает. К тому же, РП сам может зафиксировать важные для себя моменты.
Чтобы лучше понять разницу между процессным, проектным и продуктовым подходом, можно познакомиться со «стоматологической» аналогией.
Мы не оцениваем проектный и продуктовый подходы с точки зрения плохой или хороший —каждый из них применим в разных ситуациях. Для закрытия уникальной потребности лучше всего подойдет проект. А для решения типовых задач, повторяющихся у разных заказчиков, оптимален продукт
Считать ли типовые проекты продуктом? Это зависит от подхода, применяемого при реализации этих типовых проектов. Если каждый раз они выполняются «с нуля», без использования предыдущего опыта, то продуктом это назвать сложно. Если же есть типовые решения, которые применяются из раза в раз при совпадении исходных условий, то это уже ближе к продукту. А если эти типовые решения не просто применяются, но и анализируется опыт их использования, оптимизируется их функционал на основе этого анализа, то смело можем говорить о продуктовом решении.
Спасибо за комментарий!
Группа администрирования работает не только на проектах внедрения, а занимается отчетами, учетом лицензий, организацией обучения клиентов, организацией рабочего пространства для сотрудников подразделения и т.д. Также в практике два направления: продуктовое и центр внедрения. Группа администрирования работает на оба: например, тот же технический писатель занимается как проектной документацией, так и документацией для продуктов.
Если бы РП был прямым руководителем этой группы, на него легла бы дополнительная нагрузка — в виде распределения и контроля всех этих задач. Сейчас это делает Света.