В принципе логично если в корпоративном блок вещи как то связанные с этой корпорацией.
Но, наверное, интересные и показательные случаи в целом из индустрии тоже норм, особенно если сейчас по какой то причине своих нет. Читателю все равно интересно и полезно.
@UmnikSystem Удалите, пожалуйста GitHub Personal Access Token и Yandex OAuth client secret из исходного кода приложения.
После этого инвалидируйте токены в обеих системах. Ну и предупредите клиентов, если сможете, которые пользовались (и давали доступ вашему приложению к своей учетной записи) системой с момента выкладки и до момента инвалидации.
Да, обязательное условие в том, чтобы это было не «в нагрузку», а взамен.
Дежурный может (в терминах RFC :-) ) писать код, особенно если ему прямо невмоготу и он это хочет делать и если маленькая команда. Но он не должен (тоже RFC) это делать и не отчитывается за это на стендапе.
Он делает то, что разработчик хотел бы сделать, но ему некогда из за написания кода.
Самое правильное, на мой взгляд, что мы можем тут предложить или сделать — это дать выбор самому разработчику и проговорить все эти моменты заранее. Ещё на входном интервью.
Отобрать тех, кому интересен именно такой подход. Кому нужен Т-shape, а не I, причём когда дают растить его в рабочее время, а не требуют учиться когда-то в личное.
Действительно, может быть такой эффект, что специализация будет ниже, а значит если цель разработчика - прохождение тех интервью на рынке, где ценится именно I - ему будет сложнее.
Главное тут прямо и честно все проговорить на вхоже и убедиться что цели совпадают, и что разработчик следует за своими целями, просто с помощью и ресурсами компании. Принося пользу обоим.
Респект.
С первой строчки в голове заиграла эта песня.
Дедлайн - это момент, после которого уже не надо.
А почему это нужно скрывать?
В принципе логично если в корпоративном блок вещи как то связанные с этой корпорацией.
Но, наверное, интересные и показательные случаи в целом из индустрии тоже норм, особенно если сейчас по какой то причине своих нет. Читателю все равно интересно и полезно.
Спасибо, просто в статье написано, что это не так, а где - не указано. Поэтому сразу и не разобрался.
А в какой клинике происходили события из статьи?
Спасибо
Похоже, что используется трюк, аналогичный описанному тут https://github.com/MarshalX/yandex-music-api/discussions/513
Тут:
@UmnikSystem Удалите, пожалуйста GitHub Personal Access Token и Yandex OAuth client secret из исходного кода приложения.
После этого инвалидируйте токены в обеих системах.
Ну и предупредите клиентов, если сможете, которые пользовались (и давали доступ вашему приложению к своей учетной записи) системой с момента выкладки и до момента инвалидации.
Круто! А где можно почитать об этом? Сейчас очень пригодилось бы такое описание.
Тот случай, когда комментарий по ценности - как отдельная статья. ?
Расскажите поподробнее, пожалуйста. Про весь процесс, особенно про вливания, ветки, тесты и тестовые модели.
это скорее отсылка на "мышь, смотрящую на вселенную")
в следующий раз будем более аккуратно писать, спасибо.
Вот так прямым текстом это не озвучить)))
Да, это именно оно.
Есть каталог ОТАРов, на архитектурном портале.
Конкретно код ревью у нас делаю все поровну. Там нужно две «галочки» на CI чтобы он вообще поехал.
Спасибо!
Да, обязательное условие в том, чтобы это было не «в нагрузку», а взамен.
Дежурный может (в терминах RFC :-) ) писать код, особенно если ему прямо невмоготу и он это хочет делать и если маленькая команда. Но он не должен (тоже RFC) это делать и не отчитывается за это на стендапе.
Он делает то, что разработчик хотел бы сделать, но ему некогда из за написания кода.
Да! Представляете как интересно «на экскурсию» туда заглянуть?!
Самое правильное, на мой взгляд, что мы можем тут предложить или сделать — это дать выбор самому разработчику и проговорить все эти моменты заранее. Ещё на входном интервью.
Отобрать тех, кому интересен именно такой подход. Кому нужен Т-shape, а не I, причём когда дают растить его в рабочее время, а не требуют учиться когда-то в личное.
Действительно, может быть такой эффект, что специализация будет ниже, а значит если цель разработчика - прохождение тех интервью на рынке, где ценится именно I - ему будет сложнее.
Главное тут прямо и честно все проговорить на вхоже и убедиться что цели совпадают, и что разработчик следует за своими целями, просто с помощью и ресурсами компании. Принося пользу обоим.