Я не предполагал, что прочтение статьи может создать ложное впечатление о том, что все представленные примеры это привилегия исключительно декораторов. Если есть конкретные места, которые могут ввести именно в это заблуждение, пожалуйста, процитируйте их, я постараюсь их пересмотреть. Возможно не хватает какой-то части, которая помогла бы избежать недопонимания?
Вообще в данной статье я хотел показать многообразие подходов и вариантов использования декораторов в Python. Когда я только начинал программировать, я бы хотел наткнуться на статью схожую содержанием с текущей, чтобы понимать, как вообще можно использовать функционал, о котором почти во всех статьях почему-то пишут только базовые вещи, которые и так есть в документации самого языка.
Возможно я подобрал местами не самые подходящие примеры. Но в любом случае у каждого инструмента есть свои плюсы и минусы, каждый инструмент стоит использовать там, где он уместен и подходит лучше других для решения той или иной задачи.
Лично мне действительно нравится, как выглядит использование декоратора, всегда можно почти сразу понять, что именно происходит, не проваливаясь в код (если вы придерживаетесь хорошего тона в именовании переменных), так как все что нас интересует представлено списков в одном месте.
Я за последние 4 года 1 раз менял работу, 4 года назад, когда искал работу на вакансию middle python, прошел около 5-6 собеседований за 2 недели и получил 2 устраивающих меня офера, тогда у меня релевантный стаж был 2 года. В прошлом мае еще раз менял работу уже искал middle+/senior, также 2 недели откликался на все вакансии, с подходящими к моему опыту требованиями. В этот раз прошел собеседований 20 (в части компаний было несколько этапов собеседований) в итоге также получил 2 хороших оффера на сеньорскую позицию. Не знаю, насколько полезен сам отклик на вакансии в hh, но мне в основном писали hr либо в телеграм либо в вотсап. Про описанное в статье менторство слышу в первый раз, а вот резюме с "курсами" я обычно пролистываю, если именно на него сделан акцент в резюме, и я участвую в подборе специалиста, потому что не особо верю в их эффективность, Меня лично намного больше привлекают кандидаты, у которых может и нет реального опыта, но есть хоть сколько-то неплохие личные проекты и постоянные коммиты в свои репозитории
Спасибо за комментарий! Лично мне удобнее работать чисто с docker командами, но думаю в более сложных случаях это проблематично, что касается выбора окружения, я скорее бы предпочел добавление ключевого аргумента для команды
Спасибо за комментарий! В будущих статьях обращу большее внимание на "влезание" контентных блоков во фрейм ленты (сам не обратил внимание, рад, что подметили недочет). Концептуально предполагалось написать простую, среднюю и сложную статью друг за другом (следующий материал действительно будет значительно сложнее)
Спасибо за комментарий! В своих статьях я хочу сделать акцент именно на примерах и минимальных подводках к ним, потому что я сам люблю именно такой материал. Понимаю, что не всем читателям этого достаточно, поэтому и дальше буду прикреплять ссылки на статьи с более подробным описанием
Я планировал в первую очередь осветить следующие темы: декораторы, дескрипторы, контекстные менеджеры, метаклассы
Как считаете, как лучше поступить: 1) Выложить по вводной статье на каждую тему и последовательно поднимать сложность 2) Полностью закрыть каждую тему последовательно
На прошлой работе тоже был проект с отдельным репозиторием для стягивание репозиториев остальных приложений и их запуска, но до отдельной утилиты так и не добрались. Большое спасибо за комментарий, попробую тоже накидать пример с удобным разделением и запуском микросервисов
Мне казалось, что нежелательно тянуть dev, test и doc зависимости в финальный образ. Или такой подход разделения на группы релевантен исключительно для работы с библиотеками?
Я не предполагал, что прочтение статьи может создать ложное впечатление о том, что все представленные примеры это привилегия исключительно декораторов. Если есть конкретные места, которые могут ввести именно в это заблуждение, пожалуйста, процитируйте их, я постараюсь их пересмотреть. Возможно не хватает какой-то части, которая помогла бы избежать недопонимания?
Вообще в данной статье я хотел показать многообразие подходов и вариантов использования декораторов в Python. Когда я только начинал программировать, я бы хотел наткнуться на статью схожую содержанием с текущей, чтобы понимать, как вообще можно использовать функционал, о котором почти во всех статьях почему-то пишут только базовые вещи, которые и так есть в документации самого языка.
Возможно я подобрал местами не самые подходящие примеры. Но в любом случае у каждого инструмента есть свои плюсы и минусы, каждый инструмент стоит использовать там, где он уместен и подходит лучше других для решения той или иной задачи.
Лично мне действительно нравится, как выглядит использование декоратора, всегда можно почти сразу понять, что именно происходит, не проваливаясь в код (если вы придерживаетесь хорошего тона в именовании переменных), так как все что нас интересует представлено списков в одном месте.
Спасибо за комментарий!
Вот раздел PEP с мотивацией добавления этого синтаксического сахара
Спасибо за комментарий! Подберу релевантную статью к ссылке, не думал, что ошибусь именно там
Я за последние 4 года 1 раз менял работу, 4 года назад, когда искал работу на вакансию middle python, прошел около 5-6 собеседований за 2 недели и получил 2 устраивающих меня офера, тогда у меня релевантный стаж был 2 года. В прошлом мае еще раз менял работу уже искал middle+/senior, также 2 недели откликался на все вакансии, с подходящими к моему опыту требованиями. В этот раз прошел собеседований 20 (в части компаний было несколько этапов собеседований) в итоге также получил 2 хороших оффера на сеньорскую позицию. Не знаю, насколько полезен сам отклик на вакансии в hh, но мне в основном писали hr либо в телеграм либо в вотсап. Про описанное в статье менторство слышу в первый раз, а вот резюме с "курсами" я обычно пролистываю, если именно на него сделан акцент в резюме, и я участвую в подборе специалиста, потому что не особо верю в их эффективность, Меня лично намного больше привлекают кандидаты, у которых может и нет реального опыта, но есть хоть сколько-то неплохие личные проекты и постоянные коммиты в свои репозитории
Спасибо за комментарий! Лично мне удобнее работать чисто с docker командами, но думаю в более сложных случаях это проблематично, что касается выбора окружения, я скорее бы предпочел добавление ключевого аргумента для команды
conftest и правда забыл, а так директории с тестами у меня обычно на уровне приложений. И тесты уже запускаются в пацплайнах.
Статику отправляю в s3 уже c сервера тоже в пайплайнах, чаще всего статика только генерируемая
Спасибо за комментарий! Подробно об этом я расскажу в одной из следующих статей.
Спасибо за комментарий! В следующей статье будет несколько примеров регистрации.
Немного обновил верстку
Можете привести конкретный пример того, что вы имеете в виду?
Спасибо за комментарий! В будущих статьях обращу большее внимание на "влезание" контентных блоков во фрейм ленты (сам не обратил внимание, рад, что подметили недочет). Концептуально предполагалось написать простую, среднюю и сложную статью друг за другом (следующий материал действительно будет значительно сложнее)
Спасибо за комментарий! В своих статьях я хочу сделать акцент именно на примерах и минимальных подводках к ним, потому что я сам люблю именно такой материал. Понимаю, что не всем читателям этого достаточно, поэтому и дальше буду прикреплять ссылки на статьи с более подробным описанием
Я планировал в первую очередь осветить следующие темы: декораторы, дескрипторы, контекстные менеджеры, метаклассы
Как считаете, как лучше поступить:
1) Выложить по вводной статье на каждую тему и последовательно поднимать сложность
2) Полностью закрыть каждую тему последовательно
Тоже не знал, спасибо, поправлю у себя в проектах
Большое спасибо, почитаю! Я как раз работу с переменными хотел переработать, но не знал, как
Мискликнул и отклонил один комментарий. Кто бы ты ни был, прости...
Ой, супер, спасибо, переработаю эту часть у себя на проектах, реально пропустил когда-то апдейт
На прошлой работе тоже был проект с отдельным репозиторием для стягивание репозиториев остальных приложений и их запуска, но до отдельной утилиты так и не добрались. Большое спасибо за комментарий, попробую тоже накидать пример с удобным разделением и запуском микросервисов
Принял, большое спасибо, за разъяснения, пересмотрю тогда пайплайны
Мне казалось, что нежелательно тянуть dev, test и doc зависимости в финальный образ. Или такой подход разделения на группы релевантен исключительно для работы с библиотеками?