Кажется январь - официально месяц утечек данных.
Тут собрал вам ссылочек, кому интересно:
Утечка Otelier https://www.bleepingcomputer.com/news/security/otelier-data-breach-exposes-info-hotel-reservations-of-millions
Утечка у Альфа-групп https://www.securitylab.ru/news/545057.php?muid=d26eadd9-8aea-48c2-9ec4-52542c2ea51d
Утечка у Ростелекома https://habr.com/ru/news/875312/
Утечка из китайских сервисов https://cybernews.com/security/chinese-data-leak-expose-didi-weibo-kfc-communist-party/
Утечка Hewlett Packard Enterprise https://habr.com/ru/news/875230/
Подробности как обычно не раскроют, но всё равно показательно - проблемы с безопасностью есть даже у крупных компаний с деньгами. Страшно представить, как с этим обстоят дела у компаний поменьше. Уверен, что там и про пентест врятли кто-то слышал.
Тут собрал вам ссылочек, кому интересно:
Утечка Otelier https://www.bleepingcomputer.com/news/security/otelier-data-breach-exposes-info-hotel-reservations-of-millions
Утечка у Альфа-групп https://www.securitylab.ru/news/545057.php?muid=d26eadd9-8aea-48c2-9ec4-52542c2ea51d
Утечка у Ростелекома https://habr.com/ru/news/875312/
Утечка из китайских сервисов https://cybernews.com/security/chinese-data-leak-expose-didi-weibo-kfc-communist-party/
Утечка Hewlett Packard Enterprise https://habr.com/ru/news/875230/
Подробности как обычно не раскроют, но всё равно показательно - проблемы с безопасностью есть даже у крупных компаний с деньгами. Страшно представить, как с этим обстоят дела у компаний поменьше. Уверен, что там и про пентест врятли кто-то слышал.
1🆒2🔥1😱1
На всех рабочих проектах достаточно старые версии docker и docker-compose. И вот я сам не заметил, как проспал важное изменение: version в docker-compose файлах теперь можно не указывать 😎
Даже warning добавили:
#docker
Даже warning добавили:
the attribute 'version' is obsolete, it will be ignored, please remove it to avoid potential confusion#docker
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍5👀3
В этой статье расскажу о своём опыте работы в VR-шлеме, какие инструменты использую, и поделюсь советами по настройке. Возможно, это побудит вас попробовать такой формат работы и создать своё идеальное виртуальное рабочее пространство.
https://habr.com/ru/articles/876720/
На фото мой Quest 3. Кажется ему скоро будет год😎 Всё еще радует)
https://habr.com/ru/articles/876720/
На фото мой Quest 3. Кажется ему скоро будет год
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍5❤2
Еще раз убедился, что нужно фиксировать ВСЕ зависимости. Всегда.
Жили-были два пакета: jsonschema и typing_extensions. Были строго зафиксированы их версии. Всё работало 3 с лишним месяца, но сегодня при обновлении одного из стендов мы узнали, что эти два пакета несовместимы и проект больше не стартует.
jsonschema начал валится в ошибку:
Помогло изменение версии jsonschema вниз, либо поднятие typing_extensions вверх. Но ведь раньше они работали вместе, так что продолжили поиски.
В итоге всё таки нашли виновника - в requirements не было пакета referencing. Он начал подтягиваться с версией 0.36.0, вместо предыдущей 0.35.1 и всё сломал.
Лучше один раз зафиксировать всё, чем потом несколько часов разбираться.
Жили-были два пакета: jsonschema и typing_extensions. Были строго зафиксированы их версии. Всё работало 3 с лишним месяца, но сегодня при обновлении одного из стендов мы узнали, что эти два пакета несовместимы и проект больше не стартует.
jsonschema начал валится в ошибку:
TypeError: TypeVar.__init__() got an unexpected keyword argument 'default'
Помогло изменение версии jsonschema вниз, либо поднятие typing_extensions вверх. Но ведь раньше они работали вместе, так что продолжили поиски.
В итоге всё таки нашли виновника - в requirements не было пакета referencing. Он начал подтягиваться с версией 0.36.0, вместо предыдущей 0.35.1 и всё сломал.
Лучше один раз зафиксировать всё, чем потом несколько часов разбираться.
1❤5🤔4🌚2💯2
Сегодня попробовал в деле Goose. Это свежий ai-агент, который буквально вчера официально релизнулся. Сильно впечатлен.
Смысл в этом простой - цепляем его к любой LLM через API-key. Ставим задачу. Он её выполняет с помощью своих "расширений". Умеет взаимодействовать с браузером и с компьютером. Заявлена интеграция и с JetBrains, но пока не понял, в какой момент он к ним обращается.
Отправил его писать тесты на один из пет-проектов, сказал ему где искать окружение. Подсказал, что заодно будет хорошо дополнить requirements. Ну а дальше он в своем внутреннем цикле выполняет задачу.
К примеру вот так он доводит до ума неработающие тесты:
В конце он просто сдался. После 3-4х часов отладки хочется сделать так же...
Подробнее можно почитать в статье на Хабре:
https://habr.com/ru/articles/877522/
Смысл в этом простой - цепляем его к любой LLM через API-key. Ставим задачу. Он её выполняет с помощью своих "расширений". Умеет взаимодействовать с браузером и с компьютером. Заявлена интеграция и с JetBrains, но пока не понял, в какой момент он к ним обращается.
Отправил его писать тесты на один из пет-проектов, сказал ему где искать окружение. Подсказал, что заодно будет хорошо дополнить requirements. Ну а дальше он в своем внутреннем цикле выполняет задачу.
К примеру вот так он доводит до ума неработающие тесты:
─── shell | developer ──────────────────────────
command: cd /home/kisel/PycharmProjects/crew_ai && source .venv/bin/activate && PYTHONPATH=$PYTHONPATH:$PWD/proj/src pytest proj/src/bot/test_handlers.py
Я понял свою ошибку. Я использовал `side_effect` неправильно. `side_effect` нужен, когда нужно выполнить код, вместо того чтобы просто подменить функцию. В мое
м случае мне нужно подменить декоратор на функцию, которая ничего не делает.
Я уберу `side_effect` и буду использовать `return_value=mock_only_authorized`
В конце он просто сдался. После 3-4х часов отладки хочется сделать так же...
Подробнее можно почитать в статье на Хабре:
https://habr.com/ru/articles/877522/
1🔥4❤1
В 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