В PyCharm 2024.3.2 появилась поддержка uv для управления окружениями. Теперь можно создавать новые виртуальные среды с его помощью или применять uv к уже существующим. Особенно удобно это при импорте проектов из VCS — PyCharm сам предложит использовать uv.
Еще кое-что интересное — flame graph в профилировщике (доступен в Professional-версии). Он позволяет наглядно увидеть, какие части кода занимают больше всего времени при выполнении. Теперь проще находить узкие места в производительности, устанавливать пороги, искать нужные методы и детально изучать дерево вызовов.
Еще кое-что интересное — flame graph в профилировщике (доступен в Professional-версии). Он позволяет наглядно увидеть, какие части кода занимают больше всего времени при выполнении. Теперь проще находить узкие места в производительности, устанавливать пороги, искать нужные методы и детально изучать дерево вызовов.
👍4👀2
Посетил тут Moscow Python №98. В этот раз он проходил в том же здании, где находится штаб-квартира МТС-Банка. Жалко, что не было экскурсии в сам офис — всех сразу посадили в зал для конференций.
В программе три очень разные темы. Это всегда большой плюс и к кругозору, и к интересу. 🙂 Рассказывали про нейросети в защите данных, про применение SAGA-паттерна и про RPA (Robotic Process Automation) систему на Питоне.
Для себя понял, что:
- Нейросети могут быть очень быстрыми даже на обычном железе. Обрабатывать миллион файлов в корпоративной сети — реальная задача, уже можно не бояться.
- Пора бы уже подтянуть паттерны для микросервисной архитектуры. Про SAGA я даже не слышал до этого момента. Видимо, мне просто везло, и всегда хватало знать самые распространённые.
- Никогда не пойду разрабатывать RPA, ни за какие деньги. Селекторы для HTML, картинки-шаблоны для поиска кнопочек, сложности тестирования и куча других проблем... Вот когда туда заедут AI-агенты — можно будет подумать. 😄 А пока всё вручную…
С этого митапа мне запомнился один персонаж. Вы же знаете, что на митапах принято рассказывать про свои ошибки и делиться их решениями? Думаю, да. А один мужик в зале, видимо, об этом не слышал. В конце рассказа про внедрение SAGA последовал вопрос: «Ну, у вас, я так понимаю, пет-проект. А вы не пробовали нанять архитектора?» 😎
Видимо, это был автор или главный последователь фразы «Чтобы не было ошибок в коде — пишите код без ошибок». И самое страшное — он, скорее всего, кем-то руководит…
В программе три очень разные темы. Это всегда большой плюс и к кругозору, и к интересу. 🙂 Рассказывали про нейросети в защите данных, про применение SAGA-паттерна и про RPA (Robotic Process Automation) систему на Питоне.
Для себя понял, что:
- Нейросети могут быть очень быстрыми даже на обычном железе. Обрабатывать миллион файлов в корпоративной сети — реальная задача, уже можно не бояться.
- Пора бы уже подтянуть паттерны для микросервисной архитектуры. Про SAGA я даже не слышал до этого момента. Видимо, мне просто везло, и всегда хватало знать самые распространённые.
- Никогда не пойду разрабатывать RPA, ни за какие деньги. Селекторы для HTML, картинки-шаблоны для поиска кнопочек, сложности тестирования и куча других проблем... Вот когда туда заедут AI-агенты — можно будет подумать. 😄 А пока всё вручную…
С этого митапа мне запомнился один персонаж. Вы же знаете, что на митапах принято рассказывать про свои ошибки и делиться их решениями? Думаю, да. А один мужик в зале, видимо, об этом не слышал. В конце рассказа про внедрение SAGA последовал вопрос: «Ну, у вас, я так понимаю, пет-проект. А вы не пробовали нанять архитектора?» 😎
Видимо, это был автор или главный последователь фразы «Чтобы не было ошибок в коде — пишите код без ошибок». И самое страшное — он, скорее всего, кем-то руководит…
4🔥5👍2🤔2
Интересная статистика на HH есть, оказывается. Графики говорят сами за себя - конкуренция увеличилась (с 6.1 до 8.5), а количество вакансий просело в лучшем случае на 20%. Сложно сказать за бэкенд, но довольствуемся "Информационными технологиями" :)
Думаю в ближайшее время подготовлю небольшую обзорную статью про сокращения, т.к считаю это одной из самых важных тем.
Думаю в ближайшее время подготовлю небольшую обзорную статью про сокращения, т.к считаю это одной из самых важных тем.
🤯3👍2
Fullstack-разработчик - худший выбор, который можно сделать для своей карьеры в IT. Плюсов у этого решения нет, зато минусов - целый вагон.
Времена html+css+js+php прошли. Теперь вокруг каждой технологии еще несколько десятков инструментов. И всё это обновляется с бешеной скоростью. Сразу за фронтом и бэком не успеет никто. Не удивительно, что шутят про то, что фулстеки ничего не умеют. Они заслужили свою репутацию.
Фулстек будет единственным разработчиком на проекте (с большой вероятностью), потихоньку захлёбываясь в своём же коде. Почему единственным? Так его же взяли, чтобы сэкономить. Представляю, какой красивый проект получится спустя пару лет разработки без ревью и обратной связи.
Ну и вишенка на торте. Что же за компании ищут фулстеков? Те, у которых нет бюджета на двух разработчиков (фронт + бэк). Либо, по их мнению, “хватит одного, у нас не так сложно”. Чаще всего это ИП или совсем небольшие компании. У них часто странный/стрёмный стек. У них никакой “айтишной культуры”. На фулстеке будут ездить за зарплату НИЖЕ рынка. Интересные ли там проекты?ХАХА, НЕТ .
Компании маленькие. Бюджетов нет. И это значит… *барабанная дробь* Зарплата там ниже рынка, либо максимум как у среднего бэк/фронт разработчика. А ради чего столько страдать?
Развития нет, денег нет, ответственности в два раза больше… А фулстеки всё равно появляются, но зачем? Эту великую загадку решить не получилось. Если есть варианты - пишите в комменты, обсудим.
Времена html+css+js+php прошли. Теперь вокруг каждой технологии еще несколько десятков инструментов. И всё это обновляется с бешеной скоростью. Сразу за фронтом и бэком не успеет никто. Не удивительно, что шутят про то, что фулстеки ничего не умеют. Они заслужили свою репутацию.
Фулстек будет единственным разработчиком на проекте (с большой вероятностью), потихоньку захлёбываясь в своём же коде. Почему единственным? Так его же взяли, чтобы сэкономить. Представляю, какой красивый проект получится спустя пару лет разработки без ревью и обратной связи.
Ну и вишенка на торте. Что же за компании ищут фулстеков? Те, у которых нет бюджета на двух разработчиков (фронт + бэк). Либо, по их мнению, “хватит одного, у нас не так сложно”. Чаще всего это ИП или совсем небольшие компании. У них часто странный/стрёмный стек. У них никакой “айтишной культуры”. На фулстеке будут ездить за зарплату НИЖЕ рынка. Интересные ли там проекты?
Компании маленькие. Бюджетов нет. И это значит… *барабанная дробь* Зарплата там ниже рынка, либо максимум как у среднего бэк/фронт разработчика. А ради чего столько страдать?
Развития нет, денег нет, ответственности в два раза больше… А фулстеки всё равно появляются, но зачем? Эту великую загадку решить не получилось. Если есть варианты - пишите в комменты, обсудим.
1💯7🔥5😁2
Please open Telegram to view this post
VIEW IN TELEGRAM
😁2🤔1
Вы знали, что существует флоу, в котором просто нет тестировщиков? Совсем. Меня такой подход сильно удивил. И речь именно о крупных проектах, которые не жмутся за каждого человека в штате.
Мне удалось чуть нагуглить про этот подход. Вот что заявлено в преимуществах:
- Полное покрытие тестами любого кода естественным процессом.
- Не размывается ответственность. За баги в проде попадает по шапке именно тому, кто сделал фичу, а не тестировщику, который её пропустил.
- Быстрее проходит цикл разработки. Сами сделали, сами протестировали, отдали ПМу на “показ”. Меньше движений и согласований.
Вроде и здраво, но я в эту схему не верю. Огромное преимущество отдельного тестировщика в том, что он эту фичу не делал и не в курсе всех тонкостей. Бонусом к этому идут отличия в подходах и мышлении. Мы все мыслим по-своему. Могут отличаться проверки и их последовательность, а это всё повышает шансы найти больше неочевидных ошибок. И давайте не забывать огромное количество инструментов, которые придумали специально для тестирования.
И даже если каждый разработчик допинал все свои фичи до релиза, то кому же проводить регресс тестирование? А там может быть и 1000 пунктов, запросто. Многие кейсы просто так не прокликаешь. Нужно подготовить правильное состояние в БД или еще что-нибудь. Конечно можно поднатужится всей командой и пропасть на 3-4 дня. А в процессе еще и ходить на самого себя заводить задачки. Как то не вкусно.
В общем "эволюция" в обратную сторону, никак еще не могу назвать такие эксперименты. Как только проекты начали расти в сложности и размерах, всё тестирование было выведено в отдельный процесс. А здесь попытка всё упростить и придумать свой велосипед. Давайте еще весь CI/CD на разработчиков повесим. Будем 1 день писать код, 2 дня тестировать и 4 дня выкатывать.
Пошли бы работать в такую команду?💻
Мне удалось чуть нагуглить про этот подход. Вот что заявлено в преимуществах:
- Полное покрытие тестами любого кода естественным процессом.
- Не размывается ответственность. За баги в проде попадает по шапке именно тому, кто сделал фичу, а не тестировщику, который её пропустил.
- Быстрее проходит цикл разработки. Сами сделали, сами протестировали, отдали ПМу на “показ”. Меньше движений и согласований.
Вроде и здраво, но я в эту схему не верю. Огромное преимущество отдельного тестировщика в том, что он эту фичу не делал и не в курсе всех тонкостей. Бонусом к этому идут отличия в подходах и мышлении. Мы все мыслим по-своему. Могут отличаться проверки и их последовательность, а это всё повышает шансы найти больше неочевидных ошибок. И давайте не забывать огромное количество инструментов, которые придумали специально для тестирования.
И даже если каждый разработчик допинал все свои фичи до релиза, то кому же проводить регресс тестирование? А там может быть и 1000 пунктов, запросто. Многие кейсы просто так не прокликаешь. Нужно подготовить правильное состояние в БД или еще что-нибудь. Конечно можно поднатужится всей командой и пропасть на 3-4 дня. А в процессе еще и ходить на самого себя заводить задачки. Как то не вкусно.
В общем "эволюция" в обратную сторону, никак еще не могу назвать такие эксперименты. Как только проекты начали расти в сложности и размерах, всё тестирование было выведено в отдельный процесс. А здесь попытка всё упростить и придумать свой велосипед. Давайте еще весь CI/CD на разработчиков повесим. Будем 1 день писать код, 2 дня тестировать и 4 дня выкатывать.
Пошли бы работать в такую команду?
Please open Telegram to view this post
VIEW IN TELEGRAM
1👀4🤔3👍2
Не понимаю как люди пользуются DeepSeek'ом. Мощностей у них кот наплакал. 50% запросов (в лучшем случае) уходят в "Server is busy" 🤬
Please open Telegram to view this post
VIEW IN TELEGRAM
🥴8👍3🤷2👎1
Цензура в ChatGPT закончилась. Сначала подумал, что это очередные сказочки из мусорных пабликов, пока своими глазами не увидел ЭТО 🤨
Надеюсь, что это не баг, а новая фича. Работать с таким подходом намного приятнее.
P.S Пожалуй прямиком в сборник цитат "Он прост как хуй на блюдце, но при этом мощный, как ебучий локомотив. "
P.P.S Судя по новостям 12 февраля изменился подход к цензуре. Так что официально - не баг. Фича. Все посты ссылаются на обновленный Model Spec. К примеру тут: https://techcrunch.com/2025/02/12/openai-pledges-that-its-models-wont-censor-viewpoints/
Надеюсь, что это не баг, а новая фича. Работать с таким подходом намного приятнее.
P.S Пожалуй прямиком в сборник цитат "Он прост как хуй на блюдце, но при этом мощный, как ебучий локомотив. "
P.P.S Судя по новостям 12 февраля изменился подход к цензуре. Так что официально - не баг. Фича. Все посты ссылаются на обновленный Model Spec. К примеру тут: https://techcrunch.com/2025/02/12/openai-pledges-that-its-models-wont-censor-viewpoints/
Please open Telegram to view this post
VIEW IN TELEGRAM
🤣5🤯3👍1🔥1
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Апрувим?
Anonymous Poll
74%
Апрув. Главное доверять друг другу 😎
26%
Нет. Надо изучить каждую строчку 🧐
Давайте иногда вспоминать вопросы с собесов. Забывается быстро, а вспоминать всё сразу тяжело. Буду помечать хэштегом #собесы, так будет легче найти. Постараюсь поделиться именно личным опытом и чем-то полезным вокруг таких вопросов. Со временем соберём полноценную "шпаргалку".
И так, первый вопрос мне попался на Хабре, совсем недавно. Актуально и для фронтов и для бэков. Такими вопросами обычно проверяют общую "подкованность" кандидата. Лучше на них не сыпаться. И, конечно же, я позабыл ответ, пришлось погуглить.
Вопрос: Почему структурная типизация более гибкая чем номинальная?
Ответ:
Структурная типизация определяет совместимость по наличию нужных свойств, а не по именам, что позволяет использовать объекты с аналогичной структурой без явного наследования.
И так, первый вопрос мне попался на Хабре, совсем недавно. Актуально и для фронтов и для бэков. Такими вопросами обычно проверяют общую "подкованность" кандидата. Лучше на них не сыпаться. И, конечно же, я позабыл ответ, пришлось погуглить.
Вопрос: Почему структурная типизация более гибкая чем номинальная?
Ответ:
🔥5👍1
This media is not supported in your browser
VIEW IN TELEGRAM
Приехал на Python Birthday meetup. Посмотрим что сегодня расскажут 👍
👍7🔥1
Недавно прошел Python Birthday Meetup 34 в офисе Сбера на Кутузовской. Это ежегодный митап в честь дня рождения питона (20 февраля 1991 года была опубликована версия 0.9.0). Мне понравилось. Но есть нюансы.
Главная сцена впечатляет – пока что лучший зал для конференций, который я видел. Но не хватило воды! Давайте купим Сберу куллер с водой, что ли. В общем, то ли они рассчитывали, что никто не придет, то ли планировал всё ChatGPT.
Всего было 3 доклада. Первый был самый душевный – про лень и нейросети. Получился общий разбор всех AI-решений на все случаи жизни: написание кода, генерация полноценных MVP с фронтом, суммаризация созвонов, генерация презентаций и т. д. Почти всё применимо, но без ручной «доработки» всё ещё никак. Из инструментов упоминались:
Для разработки: Github Copilot, Cursor, GigaCode
Автоматизация принятия PR/MR: qodo
Создание MVP вместе с UI: V0
Для создания презентаций: Presentation AI, Gamma
Второй доклад был про асинхронщину с кучей задачек, которые естественно почти никто правильно не решил. Приложу некоторые из них в отдельном посте. Было сложно, душно и интересно. Собеседование в Точку я бы не прошёл. Ну и про асинхронный DI (dependency injection).
В третьем докладе рассказали про кейс применения Pydantic и сравнение его с остальными «аналогами» (msgspec, cerberus, marshmallow). Главный вывод такой: Pydantic самый гибкий, мощный и достаточно быстрый. Он медленнее конкурентов на порядок, но точно не будет бутылочным горлышком. Кстати, под капотом, начиная со второй версии, он написан на Rust.
Ещё успел пообщаться на стойке с ребятами из Сбера. К моему удивлению, в большинстве команд теперь доступна полная удалёнка; раньше был только гибрид (надо бы проверить на HH). Ну и, конечно же, спросил про бюрократию и объяснительные за всё подряд. Говорят, такого в большинстве команд нет. Хотя я слышал другое. Верим?
#meetups
Главная сцена впечатляет – пока что лучший зал для конференций, который я видел. Но не хватило воды! Давайте купим Сберу куллер с водой, что ли. В общем, то ли они рассчитывали, что никто не придет, то ли планировал всё ChatGPT.
Всего было 3 доклада. Первый был самый душевный – про лень и нейросети. Получился общий разбор всех AI-решений на все случаи жизни: написание кода, генерация полноценных MVP с фронтом, суммаризация созвонов, генерация презентаций и т. д. Почти всё применимо, но без ручной «доработки» всё ещё никак. Из инструментов упоминались:
Для разработки: Github Copilot, Cursor, GigaCode
Автоматизация принятия PR/MR: qodo
Создание MVP вместе с UI: V0
Для создания презентаций: Presentation AI, Gamma
Второй доклад был про асинхронщину с кучей задачек, которые естественно почти никто правильно не решил. Приложу некоторые из них в отдельном посте. Было сложно, душно и интересно. Собеседование в Точку я бы не прошёл. Ну и про асинхронный DI (dependency injection).
В третьем докладе рассказали про кейс применения Pydantic и сравнение его с остальными «аналогами» (msgspec, cerberus, marshmallow). Главный вывод такой: Pydantic самый гибкий, мощный и достаточно быстрый. Он медленнее конкурентов на порядок, но точно не будет бутылочным горлышком. Кстати, под капотом, начиная со второй версии, он написан на Rust.
Ещё успел пообщаться на стойке с ребятами из Сбера. К моему удивлению, в большинстве команд теперь доступна полная удалёнка; раньше был только гибрид (надо бы проверить на HH). Ну и, конечно же, спросил про бюрократию и объяснительные за всё подряд. Говорят, такого в большинстве команд нет. Хотя я слышал другое. Верим?
#meetups
1👍6
👍4