"Волки" или Остапы Бендеры из IT
«12 стульев» Ильфа и Петрова — одно из моих любимых сатирических произведений.
Остап Бендер, главный герой романа, — своего рода прародитель «волчества»: он демонстрирует, как умение играть по чужим правилам и искать лазейки позволяет быстрее достигать целей.
Вчера в чате скинули ссылку на статью про «волков». Так как не все еще знают этот жаргонизм, я решил тоже написать пару строк.
Вначале обрисую проблему. У нас есть «кабанчик» (жаргон 90-х — означает предпринимателя или просто бизнес), которому нужны рабочие руки, но эти руки стоят дорого, поэтому нанимать абы кого нельзя. Поэтому нужен процесс отбора кандидатов.
Сами программисты этим заниматься не любят, поэтому часть обязанностей выполняет кадровик. Здесь и возникает проблема.
HR не может объективно оценить программиста, потому что не имеет опыта в программировании. А для программистов заниматься наймом — неперспективная работа: слушать, как кандидат мямлит одни и те же ответы, — это скучно.
Кабанчик, чтобы решить эту проблему, просит программистов составить скрипты опроса, по которым прогоняют кандидатов и оценивают уже, как бы объективно.
Тут и появляются «волки». Волки — это социальные хакеры. Для них работа в IT — это игра. Играть можно по правилам кабанчика, а можно «взламывать» систему. Здесь появляется не только материальная подоплека, но и игровой азарт.
В этой игре есть четкая балльная система: чем больше ты зарабатываешь, тем ты круче.
Какие трюки используются при найме:
1. Подгонка резюме под фильтры — вставляют ключевые слова из описания вакансии, чтобы пройти автоскрининг.
2. Отработка шаблонных ответов — учат типовые вопросы/ответы и отрепетируют подачу.
3. Прозрачные уточняющие вопросы рекрутеру — выясняют этапы, критерии и таймлайны, чтобы управлять процессом.
4. Ведение нескольких процессов одновременно — чтобы не зависеть от одного оффера и иметь возможность торговаться.
5. Приукрашивание опыта — формулировки, которые не врут прямо, но создают более сильное впечатление.
6. Использование сливов/чужих скриптов интервью — ответы или задачи из прошлых собеседований адаптируют под новые.
7. Подсказки во время удалённого интервью — скрытое вмешательство извне.
8. Фальсификация рекомендаций или проектов — подделка подтверждений опыта.
А зарабатывать можно на всём и как угодно.
Перечислю основные направления:
1. Первая работа. Чем быстрее — тем лучше. 2–3 месяца максимум.
2. Мультиработа. Оптимизируй время. Удалённая работа позволяет работать на нескольких проектах сразу.
3. Проходи собеседования и продавай скрипты, вопросы/ответы, задания.
4. Проходи собеседования и продавай сливы этих собеседований.
5. Продавай услуги менторинга: собеседования, легенда, повышение зарплаты.
6. Продавай советы по трудоустройству.
Вы думаете, что в конце я начну осуждать деятельность этих ребят? Нисколько.
Большинство из приведённых выше трюков я и сам пробовал, а с 2010 по 2015 год даже работал сразу на нескольких проектах. Единственное — я не разделяю идею везде кричать, что так нужно делать.
Сегодня суббота. Кроме IT на https://job4j.ru/ мы ещё и тренируемся. Все, кто желает один час попотеть на коврике, — пишите в личку @parsentev.
«12 стульев» Ильфа и Петрова — одно из моих любимых сатирических произведений.
Остап Бендер, главный герой романа, — своего рода прародитель «волчества»: он демонстрирует, как умение играть по чужим правилам и искать лазейки позволяет быстрее достигать целей.
Вчера в чате скинули ссылку на статью про «волков». Так как не все еще знают этот жаргонизм, я решил тоже написать пару строк.
Вначале обрисую проблему. У нас есть «кабанчик» (жаргон 90-х — означает предпринимателя или просто бизнес), которому нужны рабочие руки, но эти руки стоят дорого, поэтому нанимать абы кого нельзя. Поэтому нужен процесс отбора кандидатов.
Сами программисты этим заниматься не любят, поэтому часть обязанностей выполняет кадровик. Здесь и возникает проблема.
HR не может объективно оценить программиста, потому что не имеет опыта в программировании. А для программистов заниматься наймом — неперспективная работа: слушать, как кандидат мямлит одни и те же ответы, — это скучно.
Кабанчик, чтобы решить эту проблему, просит программистов составить скрипты опроса, по которым прогоняют кандидатов и оценивают уже, как бы объективно.
Тут и появляются «волки». Волки — это социальные хакеры. Для них работа в IT — это игра. Играть можно по правилам кабанчика, а можно «взламывать» систему. Здесь появляется не только материальная подоплека, но и игровой азарт.
В этой игре есть четкая балльная система: чем больше ты зарабатываешь, тем ты круче.
Какие трюки используются при найме:
1. Подгонка резюме под фильтры — вставляют ключевые слова из описания вакансии, чтобы пройти автоскрининг.
2. Отработка шаблонных ответов — учат типовые вопросы/ответы и отрепетируют подачу.
3. Прозрачные уточняющие вопросы рекрутеру — выясняют этапы, критерии и таймлайны, чтобы управлять процессом.
4. Ведение нескольких процессов одновременно — чтобы не зависеть от одного оффера и иметь возможность торговаться.
5. Приукрашивание опыта — формулировки, которые не врут прямо, но создают более сильное впечатление.
6. Использование сливов/чужих скриптов интервью — ответы или задачи из прошлых собеседований адаптируют под новые.
7. Подсказки во время удалённого интервью — скрытое вмешательство извне.
8. Фальсификация рекомендаций или проектов — подделка подтверждений опыта.
А зарабатывать можно на всём и как угодно.
Перечислю основные направления:
1. Первая работа. Чем быстрее — тем лучше. 2–3 месяца максимум.
2. Мультиработа. Оптимизируй время. Удалённая работа позволяет работать на нескольких проектах сразу.
3. Проходи собеседования и продавай скрипты, вопросы/ответы, задания.
4. Проходи собеседования и продавай сливы этих собеседований.
5. Продавай услуги менторинга: собеседования, легенда, повышение зарплаты.
6. Продавай советы по трудоустройству.
Вы думаете, что в конце я начну осуждать деятельность этих ребят? Нисколько.
Большинство из приведённых выше трюков я и сам пробовал, а с 2010 по 2015 год даже работал сразу на нескольких проектах. Единственное — я не разделяю идею везде кричать, что так нужно делать.
Сегодня суббота. Кроме IT на https://job4j.ru/ мы ещё и тренируемся. Все, кто желает один час попотеть на коврике, — пишите в личку @parsentev.
👍17🔥6❤4🤔2🤝1
Кафка. Вопросы с собеседований: Райф, Альфа, Озон, X5, Сбер
В июле 2025 года проходил собеседования. Ниже собрал расширенный список вопросов о kafka.
1. Какие есть семантики доставки в Kafka: _at-most-once_, _at-least-once_, _exactly-once_? Что на них влияет (например,
2. При использовании _At-Least-Once_ — какие стратегии можно применить на стороне потребителя, чтобы избежать дубликатов в обработке? (например, идемпотентная обработка, детектирование по уникальному ключу, хранение уже обработанных, transactional read-process-write и т.п.)
3. В чём отличие между _At-Most-Once_ и _At-Least-Once_ по потерям/дубликатам?
4. Как работает схема _Exactly-Once Semantics_ (EOS) в Kafka? Какие компоненты участвуют и в каких ситуациях она всё ещё может не давать 100% гарантию?
5. Какие типы
6. Что означает
7. Что такое идемпотентный продюсер и почему просто
8. Как потребитель подтверждает, что он "прочитал" сообщения? В чём разница между авто-коммитом и ручным коммитом offset’ов?
9. В чём разница между
10. Что такое _consumer lag_ и как его мониторить? Почему это важно?
11. Что происходит, если оффсет не найден (например, из-за удаления старых данных)? Как работает
12. Что происходит, когда потребитель отключается от группы или добавляется новый? Как работает ребалансировка, какие стадии есть (revocation, assignment), и как её накладные расходы можно минимизировать (например, cooperative rebalancing)?
13. Что случится, если потребитель не вызывает
14. У тебя 3 брокера и топик с 3 партициями: как эти партиции распределяются по брокерам? Как выбирается лидер и реплики?
15. Что происходит при отказе лидера партиции? Как происходит failover и что такое ISR (in-sync replicas)?
16. Что случается при добавлении или удалении брокера — как перераспределяются партиции и кто инициирует ребалансировку партиций?
17. Как правильно подбирать
18. Как обеспечить атомарную обработку сообщения и запись результата в стороннюю систему (например, сравнение outbox pattern vs транзакционный read-process-write с Kafka)?
19. Как устроен механизм выбора лидера партиции и какие условия могут привести к длительной недоступности?
20. Какие метрики нужно смотреть, чтобы понимать, что потребители или продюсеры работают корректно и не теряют данные?
21. Как устроено гарантированное завершение транзакции при использовании транзакционного продюсера и как это согласуется с потребителями?
22. Как добиться минимального времени простоя при ребалансировке потребительской группы?
23. В каких ситуациях может возникнуть "split-brain" с точки зрения реплик и как Kafka с этим справляется?
Эти и другие вопросы мы разбираем на курсе по Kafka
👉 https://job4j.ru/courses/21
В июле 2025 года проходил собеседования. Ниже собрал расширенный список вопросов о kafka.
1. Какие есть семантики доставки в Kafka: _at-most-once_, _at-least-once_, _exactly-once_? Что на них влияет (например,
acks, retries, идемпотентность, транзакции)?2. При использовании _At-Least-Once_ — какие стратегии можно применить на стороне потребителя, чтобы избежать дубликатов в обработке? (например, идемпотентная обработка, детектирование по уникальному ключу, хранение уже обработанных, transactional read-process-write и т.п.)
3. В чём отличие между _At-Most-Once_ и _At-Least-Once_ по потерям/дубликатам?
4. Как работает схема _Exactly-Once Semantics_ (EOS) в Kafka? Какие компоненты участвуют и в каких ситуациях она всё ещё может не давать 100% гарантию?
5. Какие типы
acks есть у продюсера и как они влияют на задержку и надёжность доставки?6. Что означает
min.insync.replicas и как его настройка вместе с acks=all влияет на устойчивость и доступность?7. Что такое идемпотентный продюсер и почему просто
enable.idempotence=true недостаточно для полной защиты от повторной доставки в более сложных схемах?8. Как потребитель подтверждает, что он "прочитал" сообщения? В чём разница между авто-коммитом и ручным коммитом offset’ов?
9. В чём разница между
commitSync и commitAsync и когда какой использовать?10. Что такое _consumer lag_ и как его мониторить? Почему это важно?
11. Что происходит, если оффсет не найден (например, из-за удаления старых данных)? Как работает
auto.offset.reset?12. Что происходит, когда потребитель отключается от группы или добавляется новый? Как работает ребалансировка, какие стадии есть (revocation, assignment), и как её накладные расходы можно минимизировать (например, cooperative rebalancing)?
13. Что случится, если потребитель не вызывает
poll долгое время и превышает max.poll.interval.ms или теряет heartbeat (session.timeout.ms)? Как это отражается на группе?14. У тебя 3 брокера и топик с 3 партициями: как эти партиции распределяются по брокерам? Как выбирается лидер и реплики?
15. Что происходит при отказе лидера партиции? Как происходит failover и что такое ISR (in-sync replicas)?
16. Что случается при добавлении или удалении брокера — как перераспределяются партиции и кто инициирует ребалансировку партиций?
17. Как правильно подбирать
max.poll.records, max.poll.interval.ms, heartbeat.interval.ms и почему слишком длинный poll может вызывать проблемы?18. Как обеспечить атомарную обработку сообщения и запись результата в стороннюю систему (например, сравнение outbox pattern vs транзакционный read-process-write с Kafka)?
19. Как устроен механизм выбора лидера партиции и какие условия могут привести к длительной недоступности?
20. Какие метрики нужно смотреть, чтобы понимать, что потребители или продюсеры работают корректно и не теряют данные?
21. Как устроено гарантированное завершение транзакции при использовании транзакционного продюсера и как это согласуется с потребителями?
22. Как добиться минимального времени простоя при ребалансировке потребительской группы?
23. В каких ситуациях может возникнуть "split-brain" с точки зрения реплик и как Kafka с этим справляется?
Эти и другие вопросы мы разбираем на курсе по Kafka
👉 https://job4j.ru/courses/21
❤14🔥12👍3
Поднять Kafka | Minio | KeyCloak за $$$
Для проекта BuddyService нужно поднять инфраструктуру.
Пишите напрямую @parsentev.
Оплата почасовая с дальнейшей поддержкой сервиса
Для проекта BuddyService нужно поднять инфраструктуру.
Пишите напрямую @parsentev.
Оплата почасовая с дальнейшей поддержкой сервиса
❤2👍2
Как вы знаете, я большой фанат тестов: unit, it, e2e.
Одной из крутых особенностей языка Go является встроенный инструментарий для тестирования.
Тесты в Go оформляются в методологии table-driven test. В этом подходе тестовые данные и ожидаемые результаты формируются в виде таблицы. Такой подход позволяет избавиться от дублирования кода теста и при этом покрыть разнообразные случаи поведения вашей программы.
Про этот подход я знал давно, но не использовал его, потому что мне казалось: если у тебя 105 вариантов входных параметров, а падает 101, то тебе каждый раз нужно прогонять все 100 тестов.
Оказалось, что нет — IDEA Community Edition по умолчанию поддерживает запуск отдельной строки из табличных данных.
В нашем Java курсе я перепишу тесты на подход TDT.
А вы используете такой подход? Напишите свои мысли в комментариях.
—-
Наш курс по Go — https://job4j.ru/courses/38
Одной из крутых особенностей языка Go является встроенный инструментарий для тестирования.
Тесты в Go оформляются в методологии table-driven test. В этом подходе тестовые данные и ожидаемые результаты формируются в виде таблицы. Такой подход позволяет избавиться от дублирования кода теста и при этом покрыть разнообразные случаи поведения вашей программы.
Про этот подход я знал давно, но не использовал его, потому что мне казалось: если у тебя 105 вариантов входных параметров, а падает 101, то тебе каждый раз нужно прогонять все 100 тестов.
Оказалось, что нет — IDEA Community Edition по умолчанию поддерживает запуск отдельной строки из табличных данных.
@ParameterizedTest
@CsvSource({
"true,true,true,true",
"true,false,true,false",
"false,false,false,true",
"true,true,false,false"
})
void testMono(boolean a, boolean b, boolean c, boolean expected) {
Check check = new Check();
boolean[] input = new boolean[]{a, b, c};
boolean result = check.mono(input);
assertThat(result).isEqualTo(expected);
}
В нашем Java курсе я перепишу тесты на подход TDT.
А вы используете такой подход? Напишите свои мысли в комментариях.
—-
Наш курс по Go — https://job4j.ru/courses/38
🔥7
🎒 Акция: Снова в школу
Друзья, мой последний школьный звонок прозвенел ещё в 2003 году, но учиться я продолжаю каждый день.
Хочу поддержать вашу мотивацию и даю скидку на все учебные программы: −15%
Скидка действует до 30 сентября.
👉 http://job4j.ru/
Друзья, мой последний школьный звонок прозвенел ещё в 2003 году, но учиться я продолжаю каждый день.
Хочу поддержать вашу мотивацию и даю скидку на все учебные программы: −15%
Скидка действует до 30 сентября.
👉 http://job4j.ru/
🔥22❤9❤🔥2
Предал Java ради GoLang
Статьи буду публиковать на платформе, так как канал телеграмм для этого не подходит.
https://job4j.ru/article/view/1
Комментарии пока пишите тут. потом добавлю такую возможность на платформу.
Статьи буду публиковать на платформе, так как канал телеграмм для этого не подходит.
https://job4j.ru/article/view/1
Комментарии пока пишите тут. потом добавлю такую возможность на платформу.
👍18😭3🔥1
👍16
Разбор задания с первого этапа собеседования в Яндекс
https://job4j.ru/article/view/3
В приведенном коде есть явные ошибки. Я их добавил специально, чтобы обсудить. Например, мигающие тесты.
https://job4j.ru/article/view/3
В приведенном коде есть явные ошибки. Я их добавил специально, чтобы обсудить. Например, мигающие тесты.
👍4❤2🔥1
SLI/SLO/SLA
Сейчас на работе занимаюсь созданием нового микросервиса и впервые столкнулся с такими показателями.
SLI (Service Level Indicator) — метрика, по которой мы меряем качество сервиса.
Пример: процент успешных HTTP-запросов (2xx) к нашему платежному микросервису.
SLO (Service Level Objective) — целевое значение для метрики.
Пример: "не менее 99.9% успешных запросов за месяц".
SLA (Service Level Agreement) — формальное соглашение с клиентом, где закреплены SLO и последствия нарушения.
Пример: если платежный сервис падает чаще чем позволяет SLO, то мы возвращаем клиенту часть оплаты.
Как у вас на проектах, есть такие критерии?
Сейчас на работе занимаюсь созданием нового микросервиса и впервые столкнулся с такими показателями.
SLI (Service Level Indicator) — метрика, по которой мы меряем качество сервиса.
Пример: процент успешных HTTP-запросов (2xx) к нашему платежному микросервису.
SLO (Service Level Objective) — целевое значение для метрики.
Пример: "не менее 99.9% успешных запросов за месяц".
SLA (Service Level Agreement) — формальное соглашение с клиентом, где закреплены SLO и последствия нарушения.
Пример: если платежный сервис падает чаще чем позволяет SLO, то мы возвращаем клиенту часть оплаты.
Как у вас на проектах, есть такие критерии?
👍4❤3🤔2🤯2
ООП в Go. Проект Tracker. Часть 1.
Настало время показать, как в Go будет выглядеть уже легендарный проект Tracker.
Хотелось бы сразу написать по всем правилам:
Далее https://job4j.ru/article/view/4
Настало время показать, как в Go будет выглядеть уже легендарный проект Tracker.
Хотелось бы сразу написать по всем правилам:
Далее https://job4j.ru/article/view/4
❤10🔥2
ООП в Go. Проект Tracker. Часть 2.
Один из первых элементов, который я хотел разобрать в языке Go, был элемент внедрения зависимости.
После «магии» Spring DI внедрение зависимости в Go выглядит крайне примитивно.
Далее https://job4j.ru/article/view/5
Один из первых элементов, который я хотел разобрать в языке Go, был элемент внедрения зависимости.
После «магии» Spring DI внедрение зависимости в Go выглядит крайне примитивно.
Далее https://job4j.ru/article/view/5
❤7
ООП в Go. Проект Tracker. Часть 3.
Осталось рассмотреть последний элемент — реализацию полиморфизма за счёт интерфейсов. Когда я стал знакомиться с Go и спрашивать впечатления о языке у тех, кто на нём немного писал, первый негативный отзыв я услышал про «утиную типизацию».
Далее https://job4j.ru/article/view/6
Осталось рассмотреть последний элемент — реализацию полиморфизма за счёт интерфейсов. Когда я стал знакомиться с Go и спрашивать впечатления о языке у тех, кто на нём немного писал, первый негативный отзыв я услышал про «утиную типизацию».
Далее https://job4j.ru/article/view/6
👍4❤3
Обновление блока по микросервисам
Сейчас я занят переписыванием блока о микросервисах. Быстро закончить работу не получается, поэтому хочу кратко описать, какие изменения планируются, чтобы помочь тем ученикам, кто уже проходит этот блок.
Далее 👉 https://www.job4j.ru/article/view/7
Сейчас я занят переписыванием блока о микросервисах. Быстро закончить работу не получается, поэтому хочу кратко описать, какие изменения планируются, чтобы помочь тем ученикам, кто уже проходит этот блок.
Далее 👉 https://www.job4j.ru/article/view/7
👍6🔥5✍2
Как инфоцыгане сравнивают Java и Go
Неделю назад мне скинули статью, где сравнивают Java и Go. Почему мне? Потому что я сам начал писать на Go в этом году. Зачем? Что меня не устраивало в Java?
👉 Далее https://job4j.ru/article/view/8
Неделю назад мне скинули статью, где сравнивают Java и Go. Почему мне? Потому что я сам начал писать на Go в этом году. Зачем? Что меня не устраивало в Java?
👉 Далее https://job4j.ru/article/view/8
👍17❤7🔥3
💡 Code Review [#505545]
Добавил новый урок в курс «Микросервисы» - job4j.ru/courses/14
Причина появления этого урока в том, что в текущей компании очень высокие требования к качеству кода, и мне часто приходится проходить код-ревью по нескольку раз.
Кроме того, все члены команды обязаны участвовать в ревью кода других разработчиков.
Есть несколько моментов, на которые стоит обратить внимание. В уроке я подробно их разобрал, а здесь кратко расскажу для тех, кто не имеет доступа к системе.
🧩 В команде действует негласное правило: одна задача — один коммит.
Из-за этого приходится активно использовать команды:
🤔 Второй важный момент — как проводить ревью, если ты пока плохо ориентируешься в проекте.
Здесь хороший совет дал руководитель команды:
> «Не обязательно писать комментарии по коду, но обязательно смотри чужие MR».
Во-первых, так ты быстрее привыкнешь к стилю команды.
Во-вторых, код станет тебе знаком.
В-третьих, ты поймёшь, к кому можно обратиться по конкретным сервисам.
А как у вас с код-ревью: любите разбирать чужой код или больше волнуетесь, когда проверяют ваш? 😅
#job4j #программирование #codereview #микросервисы
Добавил новый урок в курс «Микросервисы» - job4j.ru/courses/14
Причина появления этого урока в том, что в текущей компании очень высокие требования к качеству кода, и мне часто приходится проходить код-ревью по нескольку раз.
Кроме того, все члены команды обязаны участвовать в ревью кода других разработчиков.
Есть несколько моментов, на которые стоит обратить внимание. В уроке я подробно их разобрал, а здесь кратко расскажу для тех, кто не имеет доступа к системе.
🧩 В команде действует негласное правило: одна задача — один коммит.
Из-за этого приходится активно использовать команды:
git rebase -i
squash
git push -f
🤔 Второй важный момент — как проводить ревью, если ты пока плохо ориентируешься в проекте.
Здесь хороший совет дал руководитель команды:
> «Не обязательно писать комментарии по коду, но обязательно смотри чужие MR».
Во-первых, так ты быстрее привыкнешь к стилю команды.
Во-вторых, код станет тебе знаком.
В-третьих, ты поймёшь, к кому можно обратиться по конкретным сервисам.
А как у вас с код-ревью: любите разбирать чужой код или больше волнуетесь, когда проверяют ваш? 😅
#job4j #программирование #codereview #микросервисы
👍13❤3
Обновление урока Гибкие методологии [#505060]
Добавил описание Scrum, потому что в текущей компании, как раз все по scrum ))
Курс 3.6. Микросервисы v.1.0 https://job4j.ru/courses/14
Добавил описание Scrum, потому что в текущей компании, как раз все по scrum ))
Курс 3.6. Микросервисы v.1.0 https://job4j.ru/courses/14
👍7
Добавил урок "Параллельные задачи Jenkins [#505549]"
На платформе job4j есть бот, который выполняет проверку и сборку проекта ученика, по сути это и есть CI. Изначально, я сделал так, что все задачи в pipeline выполняется последовательно. Это приводит к тому, что если у ученика есть ошибки и в линтере и в тестах, то ему приходится несколько раз делать исправления.
По факту эти задачи можно выполнить независимо, что даст возможность внести полноценные правки.
В курсе DevOps для этого я создал задачу, где показал, как это сделать через Jenkins. а на самой платформе я поправлю поведение CI Bot.
А вот на работе используется GitLab. Причем процессы автоматизирован на столько, что в нем есть и e2e тесты и интеграция с Jira и финальная раскатка канарейкой на прод.
Описание курса DevOps 👉 https://job4j.ru/courses/35
На платформе job4j есть бот, который выполняет проверку и сборку проекта ученика, по сути это и есть CI. Изначально, я сделал так, что все задачи в pipeline выполняется последовательно. Это приводит к тому, что если у ученика есть ошибки и в линтере и в тестах, то ему приходится несколько раз делать исправления.
По факту эти задачи можно выполнить независимо, что даст возможность внести полноценные правки.
В курсе DevOps для этого я создал задачу, где показал, как это сделать через Jenkins. а на самой платформе я поправлю поведение CI Bot.
А вот на работе используется GitLab. Причем процессы автоматизирован на столько, что в нем есть и e2e тесты и интеграция с Jira и финальная раскатка канарейкой на прод.
Описание курса DevOps 👉 https://job4j.ru/courses/35
🔥7👍5❤3🤩1
Изменения в поведение CI Bot
Сегодня обновил поведение платформы Job4j. Как я писал ранее, наш CI Bot выполнял проверки последовательно: check env → linter → test. Это было неудобно, поскольку не давало целостной картины состояния проекта.
Теперь бот проверяет все этапы сразу.
Кроме того, я убрал функцию, при которой бот, обнаружив ошибки, автоматически возвращал ответственного за задачу обратно в статус ученика. Теперь задача остаётся на проверке у ментора. Это сделано для того, чтобы ментор мог подсказать, что именно нужно исправить: в 99 % случаев ученик сам не знает, как это сделать — особенно на начальном этапе обучения.
Тема CI/CD подробно разобрана в курсе DevOps:
👉 https://job4j.ru/courses/35
Сегодня обновил поведение платформы Job4j. Как я писал ранее, наш CI Bot выполнял проверки последовательно: check env → linter → test. Это было неудобно, поскольку не давало целостной картины состояния проекта.
Теперь бот проверяет все этапы сразу.
Кроме того, я убрал функцию, при которой бот, обнаружив ошибки, автоматически возвращал ответственного за задачу обратно в статус ученика. Теперь задача остаётся на проверке у ментора. Это сделано для того, чтобы ментор мог подсказать, что именно нужно исправить: в 99 % случаев ученик сам не знает, как это сделать — особенно на начальном этапе обучения.
Тема CI/CD подробно разобрана в курсе DevOps:
👉 https://job4j.ru/courses/35
👍16🙏2