Для scala есть mcp сервер с поддержкой поиска символов, запуска тестов. Модель через 2-3 запроса обратно возвращается на запуск тестов через консоль и на grep, даже если ее настойчиво просить использовать mcp.
А мы релизы по субботам проводили, потому что в это время биржи (кроме крипты) не работают и любой факап не так страшен. У каждой компании своя специфика.
Дежурная смена это sre. Они могут откатить релиз максимум. Хорошо, если это поможет. А если новый релиз криво миграцию в бд накатил и она не откатывается? Или приложение не стартует из-за какого-нибудь кэша локального побитого? Придумывать можно много. И да, в этих случаях вызванивается разработчик.
В маленьких компаниях вообще и дежурных может не быть.
Речь не о поиске виновных, а об устранении последствий.
QA пропустил баг, который допустил разработчик. Этот баг QA должен сам исправить?
Тут уже много людей высказались, что просто нужно иметь план действий на любой факап. Не паниковать, спокойно сесть и починить. Это очень здорово работает где-то в параллельной вселенной. В нашей же даже гиганты двигающие индустрию ошибаются. Что уж говорить про маленькие компании.
Я бы назвал сбой необходимым фактором эволюции системы, после которого вырабатываются защитные механизмы. Можно и нужно перенимать опыт у других, но абсолютно всего заранее предусмотреть не получится.
Простите, что перехожу на личности. Из вашего профиля могу предположить, что вы работаете или работали в билайне. Если у вас все это есть, то откуда возникают новости подобные этой?
У нас пока 2 вида задач были. Первое это обучение конечно же. Второе это отсутствие экспертизы, когда никто в команде в полной мере не знает какую-то новую штуку, но работать с ней нужно. Оба случая на мой взгляд окупаются.
Есть ещё третий вариант, который пока не попробовали, но предстоит. Это проектирование публичного api для библиотеки, которую будут использовать другие команды. Тут чем больше глаз тем лучше. Хотя в общем случае это конечно не программирование, а написание RFC.
не решил литкод - не будет брать трубку, когда упадет прод" - это максимальное натягивание совы на глобус
Прямо как в анекдоте про спички.
Что говориться в статье? Что решение задач показывает не возможность решать задачи, а возможность действовать в стрессовой ситуации. Важно же не то решил ли кандидат задачу, а сам процесс.
Для квадратных матриц это упрощается до 2 * n^3, то есть O(n^3).
Вот именно поэтому. O(N³) на самом деле это O(kN³+C). При N стремящемся к бесконечности k и C можно опустить. Но как только вместо N подставляется конкретное число, то оказывается что и сортировка пузырьком может быть не так уж и плоха.
Это легко обходится разносом LGPL и Apache кодом по разным модулям ядра.
В одном репозитории разные файлы могут быть под разными лицензиями
Да фактически это аналог чери пика диапазона коммитов.
Почитать pro git если хочется примеров, или просто справку по rebase.
Если вы за минуту-другую разберётесь в любой командой гита, а главное поймёте, что такая команда вообще есть, то моё почтение.
Пример банальный. Есть задачка, ее нужно каитнуть хотфиксом. Самый удобный на мой взгляд способ это onto rebase на предыдущий релиз.
Сейчас я могу это сделать закрытыми глазами. 15 лет назад я понятие не имел что это, а уж тем более без косяков за пару минут не разобрался бы.
Кто-то умерет? Нет. Другие способы есть? Да! И будет выбран скорее всего он, потому что разбираться будет некогда.
Когда он понадобится, может не быть времени.
Для scala есть mcp сервер с поддержкой поиска символов, запуска тестов. Модель через 2-3 запроса обратно возвращается на запуск тестов через консоль и на grep, даже если ее настойчиво просить использовать mcp.
Вы веткой не ошиблись? Я не говорил, что кого-то нужно винить.
А мы релизы по субботам проводили, потому что в это время биржи (кроме крипты) не работают и любой факап не так страшен. У каждой компании своя специфика.
Дежурная смена это sre. Они могут откатить релиз максимум. Хорошо, если это поможет. А если новый релиз криво миграцию в бд накатил и она не откатывается? Или приложение не стартует из-за какого-нибудь кэша локального побитого? Придумывать можно много. И да, в этих случаях вызванивается разработчик.
В маленьких компаниях вообще и дежурных может не быть.
Речь не о поиске виновных, а об устранении последствий.
QA пропустил баг, который допустил разработчик. Этот баг QA должен сам исправить?
Тут уже много людей высказались, что просто нужно иметь план действий на любой факап. Не паниковать, спокойно сесть и починить. Это очень здорово работает где-то в параллельной вселенной. В нашей же даже гиганты двигающие индустрию ошибаются. Что уж говорить про маленькие компании.
Я бы назвал сбой необходимым фактором эволюции системы, после которого вырабатываются защитные механизмы. Можно и нужно перенимать опыт у других, но абсолютно всего заранее предусмотреть не получится.
Если прав ТС, то оставляем лайвкодинг как минимальный тест на стрессоустойчивость.
Если правы вы, то оставляем лайвкодинг как минимальный тест на программирование.
А лучше трёх да на одну зарплату.
Простите, что перехожу на личности. Из вашего профиля могу предположить, что вы работаете или работали в билайне. Если у вас все это есть, то откуда возникают новости подобные этой?
https://habr.com/ru/news/886000/
У нас пока 2 вида задач были. Первое это обучение конечно же. Второе это отсутствие экспертизы, когда никто в команде в полной мере не знает какую-то новую штуку, но работать с ней нужно. Оба случая на мой взгляд окупаются.
Есть ещё третий вариант, который пока не попробовали, но предстоит. Это проектирование публичного api для библиотеки, которую будут использовать другие команды. Тут чем больше глаз тем лучше. Хотя в общем случае это конечно не программирование, а написание RFC.
Иногда практикуем парное программирование.
Но есть некоторая разница. Коллега не пытается тебя оценить, он пытается помочь.
А потом инженер фесйбука во время сбоя не может открыть дверь в ЦОД. А CF роняет пол интернета. Дважды.
Прямо как в анекдоте про спички.
Что говориться в статье? Что решение задач показывает не возможность решать задачи, а возможность действовать в стрессовой ситуации. Важно же не то решил ли кандидат задачу, а сам процесс.
Потом у неустойчивого к стрессу разработчика падает прод, а он вместо мобилизации всех своих сил перестает выходить на связь.
Понятно, что разработчик не должен работать постоянно в стрессе. Но дерьмо случается, к нему нужно быть готовым.
Вот именно поэтому. O(N³) на самом деле это O(kN³+C). При N стремящемся к бесконечности k и C можно опустить. Но как только вместо N подставляется конкретное число, то оказывается что и сортировка пузырьком может быть не так уж и плоха.
А дежурное питание на pcie подаётся, или если выключить компьютер, то уже его не включить удаленно?