То, о чем написано в заголовке, совсем не раскрыто. А именно, опыт.
При этом не вижу причин не использовать ALL с пополнением ignore при необходимости.
Искал в этом статье блок, в котором оказалось бы про то, как внедряли в проекты с большой кодовой базой, какими проблемами столкнулись и как решили, но его нет 🤷 Ну раз уж нет, то поделюсь сам.
Подход 1. Хардкор
Включаем проверку всех правил и идем последовательно по всем ошибкам. В основном правим, какие-то правила добавляем в игнор. Проблема с таким подходом в том, что затрагивается весь код и процесс может занять больше количество времени. Плюс мы можем оставить баги. Плюс будет конфликт с другими ветками, если кто-то разрабатывается параллельно, что тоже может привести к багам. Из-за большого количества однотипных действий концентрация падает, как раз из-за этого в данном случае на простых действиях можно и словить ошибки.
Когда применимо? Когда проект не слишком большой и параллельно никто не занимается большими задачами.
Подход 2. Мягкий
Делал так при внедрении mypy, хорошо сработает и с ruff. Включаем все правила и пишем скрипт, который на основе текста с ошибками расставляет # noqa: XXX. И все. Заливаем в репозиторий. При конфликтах с другими ветками комментарии имеют более низкий приоритет, можно как просто скинуть noqa, либо честно решить конфликты. Далее при написании новой функциональности ruff уже работает. А при внесении правок в старый код потихоньку удалять noqa. Чтобы процесс пошел быстрее, можно создать отдельные задачи на конкретные модули, чтобы не было слишком много за раз, т.к. не хочется словить проблемы на пустом месте и не давать тестировщикам задачу протестить все приложение на глубоком уровне.
Мы поняли, что у пользователей есть привычки, которые уже устоялись и именно поэтому кажется, что так удобно и ничего менять не надо. Но если посмотреть под другим углом, то можно сделать взаимодействие с сервисом проще и быстрее: от использования более очевидных иконок до более логичного поведения интерфейса.
В этом все дизайнеры. Они знают, что пользователи привыкли к одному варианту, что нет веских причин перепиливать дизайн, но они смотрят под другим углом.
Причем изначально сервис для разработчиков, у которых есть существующие паттерны поведения. И тут оказывается, что проблема в том, что нет онбординга.
По факту из комментов с вопросами узнал больше о потребностях, чем из статьи.
В итоге-то получилось сделать так, чтобы пользователи не ходили в другие сервисы?
Не совсем так. Въезжал а Казахстан через российский паспорт, потом из Казахстана полетел в Армению по заграннику. На границе мне пальчиком ата-та сделали, но пропустили.
Если говорить об умных девайсах, телевизорах и т.п., то в ближайшее время все это может подорожать примерно на 15%
А это вообще откуда вытекает? Не из-за ОЗУ же в конце концов. Хотя в такой формулировке можно написать и по-другому: «телевизоры могут начать раздавать бесплатно и доплачивать самым красивым приобретателем». И нет никаких противоречий. Могут же.
А что mypy скажет в случае передачи key3? Вопрос риторический. В этом примере вообще нет пользы от TypedDict, ведь можно просто явно передать ключи и их типы. Можно было упомянуть namedtuple. И да, я понимаю, что это перевод, но это какой-то обрубок.
А можно узнать продолжение? Как сейчас поживает герой спустя несколько лет после описанных событий? Нашёл ли он новый способ зарабатывать больше или осознал, что есть другой путь и перешёл на него?
Если на собеседовании говорят одно, а реальности другое, грустно, конечно, но договор перед подписанием нужно читать. При этом все-таки лучше обсудить условия, не всегда ведь врут; может оказаться, что условия вам не подходят изначально, можно отказаться сразу.
Это все намного глубже.
Corax - Kafka
Sidec - Kafka Connect
Redish - Redis
Pangolin - Postgres
Syngx - Nginx
И т.д.
То, о чем написано в заголовке, совсем не раскрыто. А именно, опыт.
При этом не вижу причин не использовать ALL с пополнением ignore при необходимости.
Искал в этом статье блок, в котором оказалось бы про то, как внедряли в проекты с большой кодовой базой, какими проблемами столкнулись и как решили, но его нет 🤷 Ну раз уж нет, то поделюсь сам.
Подход 1. Хардкор
Включаем проверку всех правил и идем последовательно по всем ошибкам. В основном правим, какие-то правила добавляем в игнор. Проблема с таким подходом в том, что затрагивается весь код и процесс может занять больше количество времени. Плюс мы можем оставить баги. Плюс будет конфликт с другими ветками, если кто-то разрабатывается параллельно, что тоже может привести к багам. Из-за большого количества однотипных действий концентрация падает, как раз из-за этого в данном случае на простых действиях можно и словить ошибки.
Когда применимо? Когда проект не слишком большой и параллельно никто не занимается большими задачами.
Подход 2. Мягкий
Делал так при внедрении mypy, хорошо сработает и с ruff. Включаем все правила и пишем скрипт, который на основе текста с ошибками расставляет # noqa: XXX. И все. Заливаем в репозиторий. При конфликтах с другими ветками комментарии имеют более низкий приоритет, можно как просто скинуть noqa, либо честно решить конфликты. Далее при написании новой функциональности ruff уже работает. А при внесении правок в старый код потихоньку удалять noqa. Чтобы процесс пошел быстрее, можно создать отдельные задачи на конкретные модули, чтобы не было слишком много за раз, т.к. не хочется словить проблемы на пустом месте и не давать тестировщикам задачу протестить все приложение на глубоком уровне.
Говорить про новичков, а потом кидать dockefile с multi-stage, затем pre-commit hooks и тесты в gitlab-ci - сильно!
Хорошая статья
Дьявол познается в деталях. И в камере.
В этом все дизайнеры. Они знают, что пользователи привыкли к одному варианту, что нет веских причин перепиливать дизайн, но они смотрят под другим углом.
Причем изначально сервис для разработчиков, у которых есть существующие паттерны поведения. И тут оказывается, что проблема в том, что нет онбординга.
По факту из комментов с вопросами узнал больше о потребностях, чем из статьи.
В итоге-то получилось сделать так, чтобы пользователи не ходили в другие сервисы?
Как и Sublime text.
Видимо в опросе манагеры не участвовали, раз этого слова нет :)
Страхи у людей не те, что прежде...
Не совсем так. Въезжал а Казахстан через российский паспорт, потом из Казахстана полетел в Армению по заграннику. На границе мне пальчиком ата-та сделали, но пропустили.
Дни к отпуску хорошо монетизируются при увольнении. Само собой, если они не на уровне устных договорённостей.
Ну как сказать не просто...
@username_to_id_bot
Как-то я после Scala решил на Python писать в функциональном стиле. Исплевался. Вообще невозможно прочитать, что написано, а на Scala вообще сказка
А это вообще откуда вытекает? Не из-за ОЗУ же в конце концов. Хотя в такой формулировке можно написать и по-другому: «телевизоры могут начать раздавать бесплатно и доплачивать самым красивым приобретателем». И нет никаких противоречий. Могут же.
Перекликается с личным опытом.
А есть источник этого:
А что mypy скажет в случае передачи key3? Вопрос риторический. В этом примере вообще нет пользы от TypedDict, ведь можно просто явно передать ключи и их типы. Можно было упомянуть namedtuple. И да, я понимаю, что это перевод, но это какой-то обрубок.
А можно узнать продолжение? Как сейчас поживает герой спустя несколько лет после описанных событий? Нашёл ли он новый способ зарабатывать больше или осознал, что есть другой путь и перешёл на него?
Здесь не хватает определения, что такое IT. Если HR работает в IT стартапе, то он, получается, тоже айтишник?
Principal Engineer (L8) вообще не рядовой сотрудник. Если автор реально рассчитывает на такую зп в месяц, то он должен быть очень хорош.
Пришло время переустанавливать шиндоус
Если на собеседовании говорят одно, а реальности другое, грустно, конечно, но договор перед подписанием нужно читать. При этом все-таки лучше обсудить условия, не всегда ведь врут; может оказаться, что условия вам не подходят изначально, можно отказаться сразу.