Что лучше vs code или pycharm? Всю жизнь пользуюсь pycharm

но интересует vs code, так как поддерживает другие яп например js который я немного знаю. + У меня какие-то траблы с vps и к нему я могу подключиться только через vs code. Скажите пожалуйста ваше мнение касательно этого, стоит ли переходить на vs code и если да то возможно ли там настроить линтинг как в pycharm?

Всегда vs code пользовался

Без разницы. Но в вскод придется настраивать больше руками.

в вскоде ужасные импорты в питоне

Что не так с ними?

Зачем к впс подключаться через ide?

Это как?

ну вот ты установил FastAPI, до старлет или пидантика вскод автоматически не доберется

Бр. Фигня какая-то. Что значит "не доберётся"?

офишл совет вручную ставить глубину индексации для отдельных пакетов которые те нужны

ну напишешь class Whatever(BaseModel): ..., вскод тебе не предложит автоматически импортнуть BaseModel из пидантика

иногда нужно быстро изменения накатить на определенный скрипт

Ни разу отличий в поведении не замечал. Если известная штука - где почитать?

Зачем?

Проверить сейчас не могу, но не вижу повода для такого поведения.

а как по-другому можно сделать и сразу перезаупстить?

Деплой настроить.

Для всех модулей автоматом стоит глубина 1. Дальше первой папки он не смотрит

Пушишь изменения в репозиторий, с помощью ansible заливаешь на сервер

Комп слишком слабый, а коммитить каждое изменение, даже потенциально нерабочее — ну такое себе. А в пучарме ctrl+alt+shift+x и всё уже на серваке, удобно

Jabtanrem Hor
https://code.visualstudio.com/docs/python/settings...

Хм, гляну попозже, о чём это. Вживую проблем вообще не помню.

Зачем сразу на вас?

Не вижу как комп может на это влиять.

Нахрен потенциально нерабочее изменение на сервере?

Открой для себя удивительный мир CI/CD

На что может повлиять разница между 4 и 64 гигами оперативки? Между 4 и 12 ядрами? На моё терпение оно точно влияет

Стикер

Если на сервер не заливать, ещё быстрее будет

Забыл ещё скорость сети учесть

У меня рэббит на старте выжирает 1,5-2 ядра целиком и иногда падает. Телеграм бот может поллинг начинать по 40-60 секунд. Быстрее не будет

У меня светло в комнате

Да, в вс код очень хуевая светлая тема. Они почему-то решили, что текст не должен быть ни в коем случае контрастным

Да, это странно для редактора кода

все равно

а зачем ты постоянно перезапускаешь кролика?

Ну, если не пытаться раскочегаривать целиком систему локально, то проблем с отладкой не должно быть, а вот если по кускам локально не запускается - то ой. Я несколько раз в таком сценарии был - да, удалённая разработка выход, но по возможности лучше избегать ситуации в целом.

Е2е тесты с кукушкой

Но вообще сценариев, когда удобнее залить на сервер (если что, я не про прод, а просто шустрый сервер для разработки) и там дебажить - хватает. Если по ssh интерпретатор работает шустро, это решает проблему программирования на тапочках при хорошей связи.

Меня убеждали несколько раз. И знаете что, это пиздец. Если ты не можешь запустить юниттесты локально, то скорость разработки идёт нахуй из-за любых проблем сети. Если ты не можешь проверить новый код посредством юниттестов, значит у вас ещё и архитектурные проблемы. Короче, каждый раз когда кто-то убеждает меня, что ему позарез надо тестить на сервере - это или датасаентист (то есть не продакшн проект вообще), или говгокодер

Есть разница между "не можешь" и "можешь, но медленно". Первое - архитектурная проблема (иногда неизбежная, но об этом можно порассуждать). Второе - само по себе не проблема, но может потенциально стать проблемой, если в процессе всё на этот запуск с сервера завяжется.

Можешь но медленно применительно к юнит тестам - это не можешь. Если у тебя юниттест функции работает дольше нескольких секунд - у вас не юниттест, а какая-то хуйня

Если пилить какой-нибудь cpu-bound алгоритм, да ещё и с хорошим потреблением памяти, то как его не дроби на модули, останется что-то, что естественным образом считается долго.

Второе - не проблема. Это симптом.

Можно уменьшить количество данных в процессе тестирования. Я же не говорю полностью исключить запуск на сервере. В любом случае ты будешь гонять там. Но большую часть проверок ты должен быть в состостоянии сделать быстро и офлайн

Ну а как ты какой-нибудь поиск по графам будешь отлавливать или числодробилку? На детских примерах баги могут не проявляться, и потребление памяти тоже, а чуть больше - и надо 10 минут на итерацию локально или 1 - на заботливо выданном серваке.

Ещё раз: я не исключаю полностью тестирование на сервере. Но это не каждодневная задача

От проекта зависит. Бывает что и каждодневная.

Если каждодневная - у вас пиздец, список выше.

Ну, ты так и не рассказал, что делать в случае толстых ресурсоёмких алгоритмов и слабых компов у разработчиков.

Разделять тестирование алгоритма и тестирование эффективности алгоритма

Так а как тестировать алгоритм, если на тривиальных данных он работает, а на реальных погоду показывает?

Значит вы неправильно выделели тестовый набор. Расчехляем теорию тестирования и вперёд выделять множества эквивалентности и искать корнер кейсы

Это не всегда возможно. У меня вообще было так, что тестовые данные приходят извне и требования со временем меняются - надо адаптироваться. Любая эвристика - и мы в такой же ситуации.

Это большая проблема, которая приводит к 1. Постоянной нагрузке на разработчиков для поддержания этого кода 2. Недовольству новых разработчиков, что они не могут локально все проверить 3. Неожиданным простоям в работе сервиса

1. В кратковременной перспективе соглашусь. В долговременной - наоборот 2. Что такое sat солвер? 3. Сам же говоришь, постоянно вылезают новые кейсы, которые не были учтены. В результате софт не работает пока не обновишь

как Annotated нормально детектить? чет не пойму

Что ты имеешь ввиду?

1. Реальность плохо меняется. :⁠-⁠) 2. https://en.m.wikipedia.org/wiki/SAT_solver 3. Новые кейсы вылезают не потому что их не учли, а потому что их не было. Грубо говоря, приходят и говорят, "а если мы вот так попробуем сделать - сработает?"

1. Речь не про изменение реальности, а про количество повторов 2. Допустим. 3. "А если мы так попробуем сделать" не получится, если данный кейс не существовал. Просто не будет возможности его выполнить. А если возможность есть, значит он всегда существовал, просто не был учтен

Почему не будет возможности? Аналогия с производством: пекарня производит бублики, для этого стоит баранкозакаточная машина, печь, и т. п. Руководство хочет выпускать ещё и сушки, спрашивает — можем? Чтобы проверить, можем или нет, надо настроить баранкозакаточную машинку, подобрать параметры теста, чтобы не разваливалось и при этом сохраняло свойства, температуру и время в печи, и т. п. Кейса не было — и кейс появился. Как всё это подбирать не трогая производство? "Юнит-тестами на сковородке" ты сможешь прикинуть решение, но без нескольких десятков итераций на реальном оборудовании оно бесполезно. Решение для крупного предприятия — отдельное "серверное" оборудование для разработчиков рецептов. После этого всё ещё надо будет один-два раза довести на продакшене, но не так много. Собственно, примерно так было в случае с сат-солверами. Базовый алгоритм есть, но в зависимости от конкретного класса задач разрабатывают эвристики, которые могут вести себя лучше или хуже. Проверить — лучше получилось или хуже — можно только на конкретных задачах, а уменьшить их не получается.

Ну ещё раз: я не утверждаю что никогда нельзя юзать сервер для разработки/отладки. Я говорю, что должны быть редкие кейсы, иначе ты рискуешь оказаться в ситуации, что твой софт невозможно проверить вообще никак

Ну вот на моей практики кейсы оказываются не такими редкими. И я бы отличал ситуации, когда архитектура ломает возможность локального запуска и когда этому мешает сложность задачи.

Ну и сколько времени занимает тест такого софта в рамках PR?

Ну, на тот момент мы ими не пользовались (это научная работа была, там практики управления проектами чуть иначе были устроены), но если экстраполировать — что-то порядка пары недель. Тут ещё важно понимать, что есть тесты на корректность результата и есть — сравнительные, плана "дало ли изменение кода прирост производительности". Вот они — долгие. И поскольку это тоже задача разработчика — важно иметь удобные инструменты.

Ну я про то, что ты должен по максимуму гонять локально. Как минимум часть. Но понятно что не всё выйдет

Ну, я бы не сказал "должен", но иметь возможность — да. Если большую часть удобнее делать на сервере — почему бы не делать там всё (не теряя в процессе возможность проверить локально).

Если большую часть удобнее делать на сервере, значит у вас есть проблемы с локальным запуском. То есть, что-то мешает. Если это железные ресурсы - значит у вас недостаточно грунилярные данные. Если другие системы - слабая изоляция. Все это приведет к тому, что будет сложно поддерживать растущую систему и что-то чинить в случае каких-то проблем с конкретным стендом

Не обязательно. Возможно, что это значит, что большую часть времени (и внимания разработчика) занимает проверка производительности.

Если большую часть времени вы проверяете производительность, возможно у вас проблемы с масштабированием и вы тестируете слишком узкие кейсы. Иногда это надо, но это неустойчивый результат при хоть каком-то многообразии данных

Бр... Вся фишка тех же сат-солверов — максимально быстро найти корректный результат. И в зависимости от характера исходных данных включение и выключение эвристик и настройка параметров меняют время работы на пару порядков. ;-)

Максимально быстро найти корректный результат в конкретном кейсе? Звучит не как разработка софта, а как исследовательская работа

Ну, и исследовательская тоже. А почему исследовательская работа не должна включать в себя разработку софта? И не в конкретном кейсе, а на классе кейсов. В разработке микросхем одни задачи, машиностроении другие, криптографии — третьи. Инструмент один — параметры разные.

Исследовательская работа - это эксперименты без ожидаемого результата

Смотря что считать результатом и как эксперименты проводить.

Если есть ожидаемый результат, то это уде проверка гипотезы, а не свободный поиск =)

Ну вот если это один инструмент и разные параметры, значит он должен быть протестирован на всех возможных наборах параметров (с учётом классов эквивалентности). При чем есть тесты производительности, а есть тесты корректности. Первые скорее всего надо проводить на сервере, а вот вторые - локально, при чем максимально быстро. Если ты поменял алгоритм, недостаточно проверить что он стал быстрее, надо проверить что он все ещё работает во всех ожидаемых ситуациях

Что значит "на всех возможных наборах параметров"? Как такое может быть возможно, если инструменту постоянно новые применения находят? Собственно, У меня тема недописанного дисера была — проверить, можно ли сат-солверами решать задачи криптоанализа и каких эвристик для этого туда можно напихать. Тесты корректности в основном да, быстро делались (и то — смотря что считать корректностью). Но проверять адекватность эвристик — нужно было дофига ресурсов и брейкпоинты в местах, которые сработают через час после запуска.