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
На днях обратил внимание на то, что ruff подчищает многие импорты из typing. Это оказалось правило UP035, которое заменяет устаревшие импорты на актуальные.
Пошел искать, когда typing успел стать устаревшим. Дело оказалось в PEP 585 (https://peps.python.org/pep-0585/) начиная с Python 3.9. Вот это да!) Там прямым текстом написано "Importing those from typing is deprecated."
По ссылочке можно найти полный список того, что теперь нужно импортировать исключительно из collections.abc.
Pycharm кстати не в курсе и в первую очередь предлагает подтянуть всё из typing, а не collections. Может скажем им?)
Пошел искать, когда typing успел стать устаревшим. Дело оказалось в PEP 585 (https://peps.python.org/pep-0585/) начиная с Python 3.9. Вот это да!) Там прямым текстом написано "Importing those from typing is deprecated."
По ссылочке можно найти полный список того, что теперь нужно импортировать исключительно из collections.abc.
Pycharm кстати не в курсе и в первую очередь предлагает подтянуть всё из typing, а не collections. Может скажем им?)
1👍8
Оказывается существует модуль для обнаружения кодировки текста. Называется
Использовать максимально просто:
Вывод следующий:
#python
chardet. Под капотом оно анализирует частотность символов и структуру, находя закономерности, которые есть у разных кодировок.Использовать максимально просто:
import chardet
# Пример текста в неизвестной кодировке
text_bytes = "Привет, мир!".encode("windows-1251")
# Определение кодировки
result = chardet.detect(text_bytes)
print(result)
Вывод следующий:
{'encoding': 'windows-1251', 'confidence': 0.99, 'language': 'Russian'}#python
👍9🔥1
Вопрос: Как работает Garbage Collector в Python?
Это прям классика, встречается почти каждый раз. Если перечислите три основных механизма - уже будет достаточно :)
Ответ:
Здесь стоит выделить три ключевых механизма:
1. Подсчёт ссылок. Когда счётчик ссылок на объект падает до нуля, он удаляется.
2. Разрешение циклических ссылок. Если два объекта ссылаются друг на друга, их счётчик не упадёт до 0. Здесь нам понадобится альтернативный способ. Для разрыва циклов осуществляется обход всех объектов от "корня". Все объекты, которые не были найдены при таком обходе считаются "недостижимыми". Это и есть наши циклы и GC их удаляет.
3. Деление объектов на поколения.
Для оптимизации работы GC существует механизм "поколений". Новые объекты стартуют с generation 0. А после нескольких сборок мусора перемещаются в следующее поколение. Более старшие поколения проверяются реже, что экономит ресурсы.
#собесы
Это прям классика, встречается почти каждый раз. Если перечислите три основных механизма - уже будет достаточно :)
Ответ:
1. Подсчёт ссылок. Когда счётчик ссылок на объект падает до нуля, он удаляется.
2. Разрешение циклических ссылок. Если два объекта ссылаются друг на друга, их счётчик не упадёт до 0. Здесь нам понадобится альтернативный способ. Для разрыва циклов осуществляется обход всех объектов от "корня". Все объекты, которые не были найдены при таком обходе считаются "недостижимыми". Это и есть наши циклы и GC их удаляет.
3. Деление объектов на поколения.
Для оптимизации работы GC существует механизм "поколений". Новые объекты стартуют с generation 0. А после нескольких сборок мусора перемещаются в следующее поколение. Более старшие поколения проверяются реже, что экономит ресурсы.
#собесы
👍8🫡1
Так, 300 подписчиков сегодня празднуем или нет? 🤨
😁6❤2