Python *

Веб-разработка * Python *

14 мар в 11:57682

Два факта об int в Python

Один забавный факт привел меня к открытию другого :)

Читал Fluent Python и наткнулся на пример кода, который меня заинтересовал (помимо миллиона других, книга – топ). В главе про конкурентность и работу GIL была константа NUMBERS с необычным значением:

NUMBERS = 5_000_111_000_222_021

Нижние подчеркивания

Если не встречали в работе или документации, то вряд ли знаете (как и я): в числах можно использовать _ для читаемости. Интерпретатор их игнорирует:

>>> x = 1_2
>>> y = 12
>>> x == y
True
>>> x is y
True

Особенно удобно в высокоразрядных числах. Согласитесь 5_000_111_000_222_021 куда проще читать, чем 5000111000222021

Кеш малых чисел

Примеры ниже разбирал на домашнем ноуте с Cpython 3.13.11 и 3.14.3.

Пока игрался, меня заинтересовал один прикол. Я попробовал тот же пример с большими числами:

>>> x = 100_500
>>> y = 100500
>>> x == y
True
>>> x is y
False # Но ведь в примере выше было True..

Почему переменные больше не ссылаются на один объект?

В Cpython есть кеш для маленьких чисел, чтобы частые значения переменных не занимали много памяти и код был отзывчивее.

Ответ на вопрос: «где граница, до которой числа закешированы?» я решил не гуглить, проверил небольшим скриптом:

>>> x = 0
>>> y = 0
>>> for n in range(1000):
...     print(f'If {x=} and {y=}, x is y: {x is y}')
...     x += 1
...     y += 1

# Пропустим часть строк
If x=254 and y=254, x is y: True
If x=255 and y=255, x is y: True
If x=256 and y=256, x is y: True
If x=257 and y=257, x is y: False # Вот и граница
If x=258 and y=258, x is y: False 
...

Сначала я сделал эмпирически вывод, что закеширован диапазон 0 – 256. Но после самопроверки с гуглом узнал, что также в амортизированный диапазон входят числа от -5 до -1. Итого : от -5 до 256 включительно.

UPD 15.03.2026. Добрый дядя в комментах принес ссылку на pr в Cpython 3.15, где кеш малых чисел увеличен до 1024 :). Ух, заживем..

Для присвоения переменным чисел вне диапазона, интерпретатор начнет выделять уже раздельные области памяти и is станет возвращать False.

Так то. В оптимизации пригодится вряд ли, но удивить друзей в баре сможете.

JDTapp

11 мар в 09:112.5K

Блог компании DoubletappPython * Django * VK API *

Как проверить HTTP-запросы на Backend

Разрабатываете VK Mini Apps и хотите быть уверены, что HTTP-запросы на backend приходят именно из приложения VK, а не откуда угодно? Для этого нужна корректная проверка Init Data.

Наш backend-разработчик @dmvasiliev выложил Open Source-проект, который упрощает эту задачу. Это Python-пакет с готовыми алгоритмами проверки подлинности данных, передаваемых из VK Mini Apps. Он помогает быстро и безопасно настроить авторизацию и аутентификацию на backend-стороне приложения.

👉 Репозиторий
📘 Документация с примерами интеграции для Django и FastAPI.

Когда мы только начинали работать с VK Mini Apps, информации было немного: редкие кейсы, почти не у кого было спросить совета. За это время мы запустили несколько приложений, разобрались в нюансах платформы и накопили собственную экспертизу. Теперь делимся ею с сообществом через Open Source-проекты и вносим вклад в развитие технологии.

Репозиторий открыт — берите в работу, делитесь постом с коллегами.

А если вам нужен VK, Telegram Mini App или спецпроект на другой платформе — команда Doubletapp поможет пройти путь от идеи до работающего продукта.
Примеры наших проектов — на сайте.

men10577

9 мар в 15:354.3K

Python * TypeScript *

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

P.S. Все также бесплатно и таким останется, пока у меня есть деньги на поддержку и развитие ресурса.

DariRinch

9 мар в 12:513.2K

Информационная безопасность * Open source * Python * Windows * Искусственный интеллект

Сделать ИИ подотчетным? Теперь это реально

Пока статья набирает просмотры, выкатили DCL Evaluator - v1.1.0 с webhook API. Любой LLM pipeline получает криптографическое доказательство каждого решения за 3 строки кода. Tamper-evident. Offline-capable. 🔗 fronesislabs.com ⭐ GitHub

Python * Управление разработкой * Управление сообществом * Учебный процесс в ITСтатистика в IT

9 мар в 08:393.3K

Команда разработчиков языка программирования Python визуализировала изменение кодовой базы интерпретатора CPython в привязке к основным событиям, произошедшим за 36 лет существования проекта. За последние 10 лет объём кода на языках Python и Си в CPython практически удвоился. Для подсчёта числа строк кода использовалась утилита cloc.

Тестирование IT-систем * Python * Тестирование веб-сервисов * Тестирование мобильных приложений * Исследования и прогнозы в IT *

4 мар в 12:263.3K

44 собеса за месяца — Жив ли рынок QA/AQA на самом деле?

Последний год в IT регулярно обсуждают одну и ту же тему — рынок стал сложнее.
Вакансий меньше, требования выросли, конкуренция усилилась.

Особенно часто это можно услышать от специалистов из QA/AQA:
Мол, тестирование переполнено, вакансий мало, а найти новую работу стало почти нереально.

Я давно консультирую ребят в сфере QA и автоматизации тестирования (AQA) и регулярно наблюдаю, как специалисты выходят на рынок. Поэтому иногда вижу довольно наглядные примеры того, как ситуация выглядит на практике.

Как раз недавно один из ребят показал в нашем чатике свой календарь собеседований за декабрь — этот календарь приложил выше.

И, честно говоря, даже меня это немного удивило. За месяц у него набралось 44 собеседования.

Причём:
Во-первых, всё это происходило параллельно с основной работой.
Человек не уходил в отпуск и не ставил поиск работы на полный день — все интервью проходили между рабочими задачами.

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

Тем не менее календарь получился очень плотным.

Иногда у него было по несколько интервью в день:
HR, технички, финалки, снова HR.

А если представить его лицо 11го декабря — то лучше не надо)

P.S. Выходил на рынок он как Fullstack QA/AQA, если что. В ручном тестировании естественно ситуация похуже. Но наверное основной моей задачей и являлось помочь ему с этим переходом (QA->AQA), т.к. именно тут наилучшая конверсия для QA.

И что по итогу? Оправдались ли такие усилия?

Думаю, всем это тоже будет интересно. Стоило ли оно вообще того.

Вы реально думаете, что человек, который проходил по 6 собесов в день, мог не добиться своего?)

Всё-таки в подобной ситуации очень быстро прокачиваются навыки интервью. С каждым новым собеседованием ответы становятся точнее, технические вопросы разбираются быстрее, а уверенность растёт.

В итоге этот кандидат получил 6 офферов.

Один из них оказался особенно сильным — около 490 000 рублей gross для позиции в автоматизации тестирования.

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

Да, он действительно стал сложнее.
Да, требования выросли.

Но при этом рынок далеко не мёртв. Он просто стал требовательнее к кандидатам.

Те, кто активно выходят на рынок, много собеседуются, анализируют обратную связь и продолжают двигаться дальше — как правило, всё равно получают результат.

А те, кто не пытается, чаще находят объяснение, почему сейчас «не время».

Поэтому, когда в очередной раз услышите, что рынок QA/AQA окончательно умер, просто вспомните календарь из 44 собеседований за один месяц.

Спасибо, что дочитали пост до конца! Надеюсь, смог зарядить вас мотивацией, это была моя основная цель 🙂

В комментариях готов подискутировать на эту и смежные темы! Ну а в своем блоге Telegram также пишу про тестирование и автоматизацию, иногда затрагивая и общие темы развития в сфере IT. Всегда рад новым читателям!)

-3

dmitriy_offermate

2 мар в 14:10162

Python * Исследования и прогнозы в IT * Развитие стартапаКарьера в IT-индустрииИскусственный интеллект

Война с алгоритмами — как обойти шизу HRов.

Привет, Хабр.

Меня зовут Дима. Я разработчик и последние пару лет занимаюсь карьерным консультированием. Через меня прошло множество кейсов и за это время я чётко увидел одну вещь: поиск работы стал слишком выматывающим.

Не потому что люди слабые, а потому что процесс стал сложным, долгим и алгоритмическим.

Отклики уходят в пустоту. Резюме читают секунды. При этом сопроводительные письма либо не читают вообще, либо одним глазом.

В какой-то момент я понял: советов уже недостаточно. Нужен инструмент, который сам будет применять эти советы.

Так я решил заняться своим проектом — ИИ-ассистентом для поиска работы.

С чего всё начиналось

Идея была простой:
Находим вакансии → анализируем → генерируем письмо → отправляем отклик.

Технически всё работало.
По факту — конверсия почти не изменилась. (Кто бы мог ожидать)

Быстро стало понятно, что делать быстрее — не значит лучше.

Шаблон (даже написанный нейросетью) рекрутеры считывают мгновенно.

Что пришлось переосмыслить

То, что мы быстро поняли: ассистент должен работать как человек, а не как скрипт.

Это значит:

учитывать контекст, а не просто ключевые слова;
вытаскивать релевантные кейсы, а не перечислять стек;
писать живым языком, без «я обладаю навыками» и списков из пяти пунктов;
не создавать подозрительных паттернов поведения.

Как мы это переосмыслили

Засев на несколько недель мы перепилили всю инфраструктуру платформы и создали нечто новое.

Не буду вдаваться в подробности, но поделюсь примерным итоговым списком функций разработки:

1. Поиск релевантных вакансий

Ассистент анализирует требования и ваш опыт на уровне задач. Если компании важно «ускорить релизы», система поднимет ваш кейс про оптимизацию CI/CD.

2. Написание персонализированных сопроводительных писем

Это была самая сложная часть.

Базовая LLM пишет слишком «правильно»: канцеляризмы, одинаковая структура, списки.
Мы долго работали над стилистикой и вариативностью, чтобы письмо выглядело так, будто кандидат реально вчитался в вакансию.

3. Отчетность

У нас нет режима, который всё делает за спиной.

Вы видите какие вакансии найдены, какие письма сформированы, какие отклики отправляются, какие результаты получены.

При этом можно настраивать стратегию, скоро добавляем чёрный список компаний — по запросу пользователей.

4. Работает аккуратно

Мы сознательно внедрили естественные паузы, человеческую скорость действий, защиту от перегрузок, контроль стабильности.

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

Зачем это всё

Как карьерный консультант я вижу главное: люди тратят слишком много энергии на рутину.

Этот проект (он, кстати, называется OfferMate) не волшебная кнопка «оффер».
Это инструмент, который:

снимает техническую нагрузку,
ускоряет касание с рынком,
делает процесс управляемым.

Если интересен такой подход, то вот ссылки:

Блог проекта — здесь можно принять участие в тестировании и уточнить важные для себя моменты
Лэндинг проекта — тут базовая информация, можно почитать про функции и т.д.

Новую работу гарантировать не могу, но рутину из поиска точно уберет)

Буду рад критике. На Хабре без неё нельзя 🙂

Тестирование IT-систем * Python * Тестирование веб-сервисов * Исследования и прогнозы в IT * Карьера в IT-индустрии

2 мар в 12:26545

Русский FAANG: карьерный буст или выгорание за 400к? Что выбрать QA/AQA

В русском IT регулярно всплывает формулировка «русский FAANG» и многие хотят туда попасть. В этом посте на основе своего опыта разберу, стоит ли оно того.

Начнем с того, что каждый под словосочетанием русский FAANG подразумевает разное. Есть как минимум:
1. ВАСЯ: ВК, Альфа, Сбер, Яндекс
2. МЯСОВАТА: Mail (VK), Яндекс, Сбер, Озон, Валдберрис, Авито, Теле2, Альфа
3. Мой любимый - ОБОСРАЛСЯ: Озон, Билайн, ОККО, Сбер, Рамблер, Атол, ЛамодаТех, Совкомбанк, Яндекс

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

Так стоит ли QA/AQA и другим стремится в ВАСЯ или можно ограничится ОБОСРАЛСЯ или даже обычными мелкими компаниями / стартапами?

Чего стоит попасть туда (насколько это сложно)

У многих есть ощущение, что российский бигтех - это нечто недосягаемое. Почти как западный FAANG.

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

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

Плюс последние годы усилили тренд на оптимизацию затрат.
Ручное тестирование постепенно сокращается, а автоматизация растет. Считается, что один AQA может закрывать задачи нескольких QA.

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

Где лучше и стоит ли оно того

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

Поэтому мое личное мнение - умирать ради работы в конкретной компании вообще того не стоит.

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

В общем, тут стоит выбирать по сумме условий и не руководствоваться именем компании, т.к. оно часто ничего не значит.

Те же самые "интересные задачи" есть везде, а в стартапах они часто даже круче и челленджовее.

Что в сухом остатке

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

Всем спасибо за внимание! В комментариях готов подискутировать на эту и смежные темы!
В своем блоге Telegram также пишу про тестирование и автоматизацию, ну и в целом про карьеру в сфере IT. Всегда рад новым читателям!)

men10577

2 мар в 10:412.5K

Python * Искусственный интеллект

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

Бесплатно. Потрачено много часов работы.
Буду благодарен за фидбек и предложения.

https://ai.arckep.ru

ТРЕК 1 / NO-CODE
1.1 Введение в AI-агентов
1.2 Промпт-инжиниринг
1.3 Платформы и модели
1.4 Практика no-code
1.5 Безопасность и этика AI
1.6 Финальный проект
ТРЕК 2 / РАЗРАБОТЧИКИ
2.1 Введение в AI-кодинг
2.2 Claude Code
2.3 Gemini CLI
2.4 Codex CLI
2.5 Cursor и IDE-агенты
2.6 AGENTS.md и документация
2.7 MCP
2.8 Российские модели
2.9 Воркфлоу и OpenClaw
2.10 Финальный проект
ТРЕК 3 / OPENCLAW
3.1 Знакомство с OpenClaw
3.2 Подключение каналов
3.3 Настройка и автоматизация
3.4 Мультиагентная архитектура

+10

Feizerr

2 мар в 09:362.6K

Блог компании SelectelЗанимательные задачкиPython * Программирование * Математика *

Задача о сравнении чисел

Привет, Хабр! Как насчет небольшой задачи, чтобы вкатиться в рабочую неделю?

Условие

В IT-компанию N привезли экспериментальное устройство для автоматизации расчетов. Оно работает на урезанном интерпретаторе Python: никаких условий, сравнений или встроенных функций — только арифметика и битовые операции.

Знаки сравнения (>, < == и другие) использовать не получится, интерпретатор их не поймет и выдаст ошибку. Однако без них писать код довольно сложно. Придется реализовать базовую логику выбора большего из двух чисел.

Задача

Есть два числа: a и b. Найдите наибольшее из них, используя только сложение, вычитание, деление и умножение, а также битовые операции.

Нельзя использовать операторы сравнения (>, <, ==, != и т. д.), тернарный оператор, функции вроде max(), min() и прочее.

Попробуйте справиться с заданием. А один из вариантов решения показываем в Академии Selectel.

+14

DariRinch

2 мар в 05:503.1K

Информационная безопасность * Python * Машинное обучение * Искусственный интеллектФинансы в IT

Детерминистический аудит-слой для LLM-агентов — открытое демо

Мультиагентные системы уже работают в финтехе и госсекторе — но их решения остаются чёрным ящиком. Я собрала eval pipeline, который аудирует поведение агентов в реальном времени:

→ Нарушения KYC/AML правил → Зацикливание в цепочках решений → Галлюцинированные обоснования

Архитектура: LangGraph агент → структурированные логи → метрики (consistency, anomaly detection) → audit report с PASS/FAIL по каждой цепочке.

Работает на любой модели через LiteLLM — меняешь модель одной строкой в config.yaml. API-ключ не нужен, есть рабочий Jupyter notebook.

Ориентировано на финтех и госсектор: EU AI Act, ФСТЭК.

Демо: github.com/DariRinch/dcl-eval-pipeline-demo

Высоконагруженные системы * Веб-разработка * Python *

1 мар в 18:30193

Экономия памяти со __slots__

В Python атрибуты классов по-умолчанию хранятся в специальном dunder-атрибуте __dict__. В описании класса его задавать не надо, он есть неявно и доступен для просмотра при необходимости. Каждый экземпляр класса также имеет свой __dict__:

class Standard:
	def __init__(self, x, y):
		self.x = x
		self.y = y
		
std = Standard(100, 200)
std.__dict__ # {'x': 100, 'y': 200}

Помимо того, что и класс и экземпляры отдельно занимают своими __dict__ место в памяти, хранение данных в словарях само по себе несет большие накладные расходы. Хеш-таблица в основе словаря хранит служебные структуры и растёт скачками при увеличении числа атрибутов, поэтому на больших количествах объектов затраты памяти ощутимы:

from sys import getsizeof

std_size = getsizeof(std) + getsizeof(std.__dict__)
std_size # 344 байта

Один из эффективных способов сэкономить память, это реализовать в классе специальный атрибут __slots__ и объявить в нем последовательность атрибутов экземпляра. Тогда вместо __dict__, Python будет использовать альтернативную структуру хранения атрибутов с помощью дескрипторов. __slots__ для экземпляров классов отдельно не создается и хранится только на уровне класса:

class Slot:
	__slots__ = ('x', 'y') # Неизменный кортеж из имен атрибутов
	
	def __init__(self, x, y): # Остальное – без изменений
		self.x = x
		self.y = y
		
slt = Slot(100, 200)
slt.__dict__ # **AttributeError**: 'Slot' object has no attribute '__dict__'. Did you mean: '__dir__'?

slt_size = getsizeof(slt)
slt_size # 48 байтов

Так добавив одну строчку кода, можно сэкономить расходы памяти в приложении, где требуется создавать миллионы одинаковых объектов.

---
Важные ограничения

Стоит отметить, что реализация __slots__ запрещает динамически добавлять экземпляру класса атрибуты, в отличие от __dict__. В ситуациях, где такое необходимо, __slots__ не подойдет.
```
std.z = 300
std.__dict__ # {'x': 100, 'y': 200, 'z': 300}

slt.z = 300 # **AttributeError**: 'Slot' object has no attribute 'z' and no __dict__ for setting new attributes
```

Важно, не забывать расширять слоты, если мы добавляем в код класса новые атрибуты:

class PartialSlots:
	__slots__ = ('x', 'y') # Не добавили атрибут экземпляра 'z'
	
	def __init__(self, x, y, z):
		self.x = x
		self.y = y
		self.z = z

p = PartialSlots(100, 200, 300) # **AttributeError**: 'PartialSlots' object has no attribute 'z' and no __dict__ for setting new attributes

В подклассах от класса со __slots__ наследование этого атрибута проходит лишь частично. Для полноценного использования, его стоит определить еще раз, включив новые атрибуты подкласса:

# Подкласс без доп. логики
class InheritSlot(Slot):
    pass


inh_slt = InheritSlot(100, 200)

inh_slt.__dict__ # {}, атрибут снова доступен
inh_slt.z = 300 # Нет ошибок при динамическом расширении атрибутов
inh_slt.__dict__ # {'z': 300}, словарь подкласса снова занимает память

# Поправим
class InheritSlot(Slot): 
     __slots__ = ('z', ) # Слоты суперкласса добавятся в начало кортежа. В конце не забываем запятую, так как это кортеж из одного элемента.


inh_slt2 = InheritSlot(100, 200, 300)
inh_slt2.__dict__ # AttributeError ... теперь слоты используются корректно в подклассе

LamedGroup

26 фев в 16:55933

Python * Программирование * Анализ и проектирование систем * Управление разработкой * Бизнес-модели *

Не пойму — чего за кипишь? Или почему ИИ — это просто новый «питон»

Последнее время из каждого утюга кричат: «ИИ заменит программистов!», «Джуны больше не нужны!», «Учитесь на сантехников, пока не поздно!».

Давайте выдохнем, отставим смузи и разберемся по-простому, «на пальцах», что вообще происходит.

1. Программист — это не «печатающая машинка»

Главная ошибка паникеров в том, что они путают набор текста с программированием. Если ваша работа заключалась в том, чтобы копипастить методы из Stack Overflow и менять там названия переменных — да, у меня для вас плохие новости. ChatGPT делает это быстрее и без обеденного перерыва.

Но программист — это не тот, кто знает, где поставить точку с запятой. Программист — это переводчик. Мы переводим смутные человеческие «хотелки» на жесткий язык логики, понятный машине.

2. Эволюция «костылей»

Вспомните историю. Раньше писали на перфокартах. Потом на Ассемблере. Потом на Си, потом на Питоне. Каждый раз кричали: «Ну всё, теперь порог входа стал таким низким, что программисты не нужны!». И что? Программистов стало только больше. Просто мы перестали думать о том, в какой регистр положить байт, и начали думать о том, как построить архитектуру сервиса.

ИИ — это просто следующий уровень абстракции. Это новый «язык программирования», где вместо скобочек мы используем новый язык -конструкты чистого смысла

3. Проблема «идеального мусора»

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

4. ИТ-поликлиника

Представьте, что в больнице появился робот-санитар, который идеально моет полы и делает уколы. Означает ли это, что врачи-хирурги или диагносты больше не нужны? Наоборот! Теперь им не нужно отвлекаться на мытье полов.

А кого вообще не заденет? (Спойлер: Работы будет завались)

Если вы думаете, что ИИ — это такой терминатор, который выкосит всё ИТ-отделение, то вы плохо представляете, как устроена реальная «цифровая больница». Есть куча специализаций, где человеческий фактор — это не баг, а фича.

Архитекторы сложных систем (System Architects): ИИ может нарисовать типовой домик. Но построить небоскрёб на болоте, учитывая старое «дырявое» железо, бюджет заказчика и планы на 10 лет вперёд... ИИ не видит контекста «выживания» системы, он видит только код.
Инженеры кибербезопасности (SecOps): Тут идёт вечная война хитрости. ИИ может искать паттерны, но он не может предугадать нестандартный «выверт» хакера-человека. Безопасность — это интуиция и паранойя, а у нейронок с этим туго. Гы)))
SRE и DevOps (Те, кто спасают сервера в 3 часа ночи): Когда у системы «инфаркт», данные текут, а клиенты кричат — нужен человек с железными нервами, который примет решение «резать или шить». ИИ в критической ситуации может просто выдать ошибку 404, потому что такого случая не было в его обучающей выборке.
Бизнес-аналитики и «Психотерапевты заказчика»: Это те, кто переводят с «бреда руководства» на человеческий. ИИ никогда не поймет, почему директор хочет «кнопку как у конкурентов, но чтобы она была синей, но красной».
Процессные аналитики (BPM): Они рисуют, как ходят бумажки и данные между отделами. ИИ учтёт, что бухгалтер Марья Ивановна просто не отдаст отчёт вовремя, потому что обижена на айтишников?
Итог

Ребята, расслабьтесь. Программирование не умирает, оно взрослеет. Уходит эпоха «кодинга ради кодинга». Наступает эпоха Качества Мышления. Теперь важно не то, насколько быстро ты стучишь по клавишам, а то, насколько структурированно ты умеешь формулировать смыслы.

ИИ — это просто наш новый, очень мощный экзоскелет. Но куда в нем идти и зачем — решать всё равно вам.

Так что идите пить чай, делайте зарядку для мозгов и учитесь формулировать. Это единственный навык, который у вас никто не отберет.

dmitriy_offermate

26 фев в 14:12185

Python * Исследования и прогнозы в IT * Развитие стартапаКарьера в IT-индустрииИскусственный интеллект

Как я написал 87 000 сопроводительных писем - про разработку помощника для поиска работы.

Сразу уточню - писал сопроводительные само собой не сам.
Мы с командой работаем над ИИ-ассистентом для поиска работы и эти 87 000 писем были отправлены пользователями сервиса в рамках бета-тестирования.

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

Задача

Изначально мы хотели решить довольно простую на первый взгляд проблему: автоматизировать написание сопроводительных писем.

Но быстро стало понятно, что «просто генерировать текст» - бессмысленно.

Цель изменилась.
Нужно было не просто прикладывать письмо к отклику, а сделать его:

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

И вот тут начались сложности.

С чем столкнулись

Шаблонность моделей.
Даже при хорошем промптинге тексты начинали повторяться по структуре и формулировкам.
Разные ожидания HR.
Кто-то предпочитает краткость, кто-то - структуру, кто-то - конкретные достижения в цифрах.
Изменяющиеся требования вакансий.
Один и тот же стек может быть описан по-разному, и формальное совпадение по ключевым словам не гарантирует релевантности.
Ограничения платформ.
Изменения на стороне hh влияли на логику работы системы, и часть архитектуры приходилось пересобирать.

В какой-то момент стало ясно, что проблема глубже.

Главный вывод

После десятков тысяч писем стало очевидно:

Проблема не в том, что сопроводительные «плохие».
Проблема в том, что в них не видно релевантности.

HR тратит на письмо буквально несколько секунд.
Если за это время не становится понятно, почему кандидат подходит - письмо закрывается.

Поэтому мы изменили подход.

Система теперь не «пишет красиво».
Она сначала сопоставляет требования вакансии с опытом пользователя и только потом формирует текст, где это соответствие явно показано.

Что изменилось в результате

После 87 000 отправленных писем тексты стали короче, конкретнее, привязанными к требованиям вакансии, менее шаблонными.

Ну а параллельно дорабатывались и другие части системы:

фильтрация релевантных вакансий
автоматизация откликов
работа с онлайн-тестами
механизмы приоритизации

Что по итогу имеем сейчас

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

История с сопроводами по большей части пройдена, но осталось ещё множество аспектов для улучшений.

Кому интересно - могут попробовать бота бесплатно. В блоге можно найти более подробную информацию. Также там пишу про развитие проекта и проблемы, с которыми сталкиваемся.

Welcome: https://t.me/offermatecrew

SystemSoft

22 фев в 15:116.3K

Python * Raspberry Pi * DIY или Сделай самОперационные системы

Здравствуйте! Сегодня хочу вам представить микроядро rMach.

Это проект микроядра в 700 с чем то строк кода. Финальный билд говорит что ядро потребляет 19.9 кб в RAM.

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

Я реализовал там:

Reference counting (на порты) - чтобы не жрали память порты которые не кто не использует.
Send once (право SERVER) - да, он самый.
VM для изоляции и вытеснение. Нет, не virtual memory, а virtual machine.
Handoff scheduling - имеет недочёты, но в целом работает.
O(1) планировка на ~~стероидах~~ битовых масках.
IPC на портах - как в Mach.

Да, снова MicroPython, но уже думаю над C.

А что с Pech? Да ну так себе - к примеру можно обойти изоляцию зная фичи Python'а.

Взломать rMach почти не возможно. Не обещаю, но вроде не возможно.

Как всегда (нет) - пост хотел в "Я пиарюсь", но - карма не позволяет.

Ссылка: https://github.com/SystemSoftware2/rMach

Если найдете баг - пожалуйста, скажите, я буду рад.

Также пример программы на моей VM:

CREATE_PORT
STORE my_port

PUSH 42
PUSH 0
FETCH my_port
SEND

FETCH my_port
RECV
PRINT
HALT

Удачи!

Open source * Python * Алгоритмы * Обработка изображений *

22 фев в 09:277.4K

Представлен открытый проект rembg — легковесный скрипт на Python, который поможет убрать фон даже с самых сложных картинок. Удаляет фон за секунды и не грузит ПК.

Информационная безопасность * Open source * Системное администрирование * Python * Софт

16 фев в 05:026.5K

Открытый проект Dangerzone позволяет преобразовать любой документ в безопасный PDF. Решение работает с , таблицами, картинками и другими форматами документов, распаковывает и проверяет их в изолированном пространстве — даже если внутри вирус, локальному ПК ничего не грозит. На выходе получается безопасный файл для просмотра.

Open source * Python * Rust * Учебный процесс в ITКарьера в IT-индустрии

15 фев в 04:526.9K

Открытый проект Cheat-Sheets предоставляет учебны материалы для Python, Rust, Swift, JavaScript, Kotlin, Go, Git, и других проектов. Там есть все важнейшие концепции, правила, стили программирования, фреймворки, библиотеки и прочее. Внутри также курсы по Git, Docker, базам данных, а также алгоритмам. Все материалы разделили по уровням сложности, к каждой главе есть контрольные вопросы и десятки задач. Все концепции авторы объясняют на конкретных примерах и разжевывают до последней строчки кода.

TheStupidBear

13 фев в 09:044.4K

Всем привет. Хотелось узнать, сложно ли развивать Telegram бот.
Нашел на просторах habr такую статью:
https://habr.com/ru/articles/778588/
Мой бот только на русском языке, поэтому статьи писал на Яндекс Дзен (0 просмотров, пост скорее всего удалили), DTF (лучший источник пользователей, комментят и заходят в бота), habr (написал пост-рекламу - не помогла).
Еще есть реддит, но я новый пользователь (там с этим беда - карма маленькая (попаду в ад)).

Что посоветуйте делать? Только не бейте)
Ну и соответственно ссылка на бота:
http://t.me/drinking_buddy_2025_bot

Всем спасибо)

-2

12 фев в 11:004.8K

Python * Исследования и прогнозы в IT * Развитие стартапаКарьера в IT-индустрииИскусственный интеллект

Про Созвоны

Любой руководитель в распределенной команде сталкивался с ситуациями, когда команда начинает гореть от созвонов. Спринт задачами набили, оценили, а потом половину не сделали. Из-за чего? Не попали в оценки. Были влеты..

А еще была куча общих встреч, ретро, планнингов, скрам-баннингов и интерраптов, которые на доске и в таймшите не увидишь.

Инженеры так не любят созвоны, потому что у них неосязаемый импакт и definition of done. Они мыслят задачами, мерж-реквестами, зелеными тестами, чем-то с измеримым результатом. Сел за задачу, вник и сделал. КПД в идеальных условиях напоминает воркера. В очередь пришла задача — он ее обработал и закрыл, ждет следующую. В перерывах гладит кота или пузо.

Когда инженер сидит на звонках, которые его напрямую не касаются, его пропускная способность падает из-за ложных сигналов. Он не может нормально параллельно работать. Надо либо час вникать, либо мозг выключается в мемы, либо на встречу в принципе забивают. Многие созвоны вообще не для инженеров. Они для менеджеров.

Для внеплановых статусов менеджер не всегда заранее знает, кто ему по факту нужен, и зовет «на всякий». На созвонах, кроме ведущего и ЛПР, участники в принципе нужны подстраховать. Вася может понадобиться. А может и не понадобиться. И опять сидит Вася без камеры, без микрофона и грустит. Ждет, когда все закончится, чтобы вспоминать, на чем он там остановился.

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

Кто поможет создать правильный шумовой барьер и дать команде работать, при этом отдавая в проектный офис нужную информацию? Как по мне, это не обязательная боль инженера. Побороть проблему — роль хорошего лида.

Урон от звонков надо вбирать в себя лиду. Его обязанность — знать контекст по верхам о проблемах и задачах вверенной команды. Отстаивать их интересы, обрабатывать обратную связь. Таков путь, отделяющий лида от сеньора-помидора.
Лиду надо собирать дашборды, таблицы, фильтры, регламенты, схемы. Запросы на оперативную информацию не должны отнимать ресурсов. Все по полочкам: база знаний, закладки, конфля, raycast шорткаты, ИИ-агента с MCP натравить на Confluence и Jira (если ИБ по шапке не даст). Надо и свой ресурс беречь и дать просящему удочку вместо рыбы.
От лишних звонков можно отказываться. Без конфронтаций, просто фильтровать: «А зачем? Вот все ответы на вопросы». Либо можно договориться многие задачи сделать асинхронно. Таска в джире с исполнителем и сроком и поехали.
Проектам нужна карта компетенций. Для тех ситуаций, где нужно глубже вникнуть в предметную область, это ок — привлечь инженера вместо лида. Важно знать, какого. Классический мем: девять женщин не могут родить ребенка за месяц. С этим стереотипом «больше-лучше» карта компетенций помогает бороться.
Звонок на час — плохой дефолт. 45 минут — уже лучше. 30 минут — еще лучше. 15 можно не ставить, есть мессенджер и почта.
Звонки должны ставиться по календарю. Вызванивать минута в минуту — моветон хотя бы потому, что есть правда неотложные ситуации. Но не все звонки — неотложные.
У звонков должны быть повестки. Приглашенные должны иметь возможность понимать, о чем пойдет речь. В идеале, нужна ссылка на доки или задачи. Без этого участники идут на звонок вслепую и тратят время, чтобы понять, что от них хотят.

Побуду адвокатом дьявола. На некоторые звонки команду лидам брать надо. Так можно узнать полезную информацию с полей. Ребята могут раскрыться, вовлечься. Вполне смогут затащить какой-то каверзный проект и унести его в перфоманс ревью.

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

Зло — звонки не оптимизировать. А инженера с его очередью лучше оставить в цикле и не засорять эфир.

dmitriy_offermate

9 фев в 12:165.1K

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

Привет, Хабр.

В декабре наш ИИ-ассистент для поиска работы фактически перестал работать.
Изменения на стороне платформ, ограничения, поломанные сценарии - всё то, из-за чего большинство подобных проектов обычно закрываются или уходят в «заморозку».

Самый логичный вариант был простой:

«Ну ок, рынок поменялся, едем дальше».

Но мы решили иначе.

Мы не смогли смириться с тем, что квалифицированные специалисты по-прежнему тратят часы жизни на клики, шаблонные отклики и бесполезную рутину.
Поэтому вместо точечных фиксов мы решили не чинить старое, а пересобрать всё с нуля.

Так начался путь к OfferMate 2.0.

Главная мысль оказалась неожиданно простой:

Автоматизация должна быть не только быстрой, но и естественной.

Настоящий цифровой ассистент должен вести себя как человек:

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

Именно вокруг этого принципа мы и пересобрали архитектуру продукта.

Что теперь умеет OfferMate 2.0

🤖 Отклики только на релевантные вакансии
Ассистент анализирует ваш опыт и требования работодателя и выбирает вакансии, которые действительно подходят, а не просто совпадают по ключевым словам.

👤 Имитация человеческого паттерна поведения
Система воспроизводит действия пользователя: паузы, разную скорость, приоритеты.
Это делает работу максимально естественной и безопасной.

✍️ Персонализированные сопроводительные письма
Каждое письмо формируется под конкретную вакансию и компанию - на основе вашего опыта и требований позиции.

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

🧩 Новые функции

автоматическое прохождение онлайн-тестов;
поддержка одновременных откликов с нескольких аккаунтов.

Про релиз

12 февраля в 12:00 мы открываем доступ к OfferMate 2.0.

Первая волна будет ограничена 50 пользователями, а доступ открыт на 3 дня.
Это осознанное ограничение - чтобы сохранить стабильность системы и быстро собрать качественную обратную связь.

Поучаствовать в тестировании в числе первых можно будет в нашем телеграм канале, в нём делимся всеми новостями проекта:

👉 https://t.me/offermatecrew

Буду рад вопросам и обсуждению в комментариях

DirtyHornet

9 фев в 11:455.1K

Я выпустил новую версию библиотеки для работы с МЭШ (Московская Электронная Школа)

https://github.com/xd2dd/schoolmospy

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

Open source * Python * Учебный процесс в ITКарьера в IT-индустрииЗвук

8 фев в 09:287.1K

Открытый проект ebook2audiobook превращает любую электронную книгу в полноценную аудиокнигу. Работает просто: закидываете epub, pdf или даже обычный txt и на выходе получаете готовый аудиофайл с главами, нормальной озвучкой и метаданными. Подойдёт, если не любите читать глазами, но хотите слушать книги в дороге или на тренировке. Работает локально на ПК и поддерживает множество языков и даже умеет клонировать голос. Можно озвучить книгу своим голосом или профессиональным диктором. Идеально для студентов, тех кто учит языки, или просто хочет слушать свои книги офлайн без подписок и облаков.

Python * Учебный процесс в ITКарьера в IT-индустрии

7 фев в 15:3510K

Обновлён учебный курс Welcome to the Python Programming Hub по Python с полного нуля до уровня продвинутого разработчика за 3 месяц. В репозитории сотни материалов для изучения Python, а также Data‑аналитики, машинного обучения, Data Science. Там есть вся база по Python с первых строчек кода до комплексного ООП, лямбда‑функций, замыканий и других сложных концепций языка. Изучение всех необходимых базовых библиотек, которые должен знать каждый уважающий себя разработчик на Python: JSON, Math, NumPy, Pandas, а также фреймворка Django. Материалы по всем актуальным и полезным API, машинному обучению, распознаванию речи, парсингу, компьютерному зрению, работе с изображениями и даже видео, алгоритмам и автоматизации процессов. Также даётся детальное представление о различных специализациях Python‑разработчиков, которые можно освоить и реализовать несколько пет‑проектов. В каждой главе представлены исчерпывающие примеры кода, картинки, объяснения, квизы и контрольные вопросы.

ilya_mk

7 фев в 12:057.7K

Python * Node.JS * Управление разработкой * КиберпанкИскусственный интеллект

лайкните пост кто сейчас вайбкодит свои продукты и напиши в комментах что делаете. очень интересно!

-24

Тестирование IT-систем * Python * Тестирование веб-сервисов * Тестирование мобильных приложений * Тестирование игр *

6 фев в 14:027.7K

Почему хороший тестировщик — это не тот, кто нашел больше всего багов

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

На практике все сложнее. И чем опытнее становится тестировщик, тем реже он гордится просто цифрами.

Количество багов ничего не говорит само по себе

Сто найденных дефектов могут означать две совершенно разные вещи:

продукт реально нестабилен;
тестирование началось слишком поздно.

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

Сильный тестировщик думает раньше, чем тестирует

Тестирование начинается не с чек-листов и не с автотестов. Оно начинается с вопросов.

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

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

Баг-репорт — это не обвинение

Новички иногда воспринимают баг как доказательство чьей-то ошибки. Отсюда агрессивные формулировки и желание «поймать» разработчика.

Опытный тестировщик понимает — баг-репорт это способ помочь команде. Хорошее описание проблемы экономит время всем:

понятно, что сломалось;
понятно, как воспроизвести;
понятно, почему это важно.

Чем меньше эмоций и больше контекста — тем лучше работает процесс.

Автотесты — это не самоцель

Автоматизация часто превращается в гонку — у кого больше тестов, у кого выше покрытие. Но цифры сами по себе ничего не гарантируют.

Хороший тестировщик задает другие вопросы:

ловят ли эти тесты реальные проблемы;
можно ли им доверять;
не мешают ли они менять код.

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

Хороший тестировщик думает о пользователе, а не о сценарии

Чек-листы и тест-кейсы важны, но реальный пользователь почти никогда не действует по ним.

Он кликает не туда, вводит странные данные, прерывает процессы и возвращается позже. Умение выйти за рамки сценариев отличает опытного тестировщика от формального.

Качество — это ответственность всей команды

Одна из самых токсичных идей в тестировании — что за качество отвечает только QA. Это удобно, но не работает.

Сильный тестировщик не берет качество на себя полностью. Он помогает команде видеть риски, объясняет последствия и участвует в решениях. Но ответственность остается общей.

Карьерный рост в тестировании — это не про инструменты

Инструменты меняются быстро. Сегодня один фреймворк, завтра другой. Знание конкретного тулкита редко определяет уровень специалиста.

Гораздо важнее:

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

Именно это делает тестировщика ценным, а не список технологий в резюме.

В итоге

Хороший тестировщик — это не тот, кто нашел больше всего багов. Это тот, кто:

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

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

TheStupidBear

6 фев в 13:404.9K

Python * ГовнокодIT-инфраструктура * Яндекс API *

Сразу оговорюсь, это пост- реклама.

Написал Telegram бота для знакомств (поиск собутыльника). Пользователь отправляет свою геопозицию (широту и долготу), а боту нужно предложить людей, живущих рядом.
Нашел на просторах интернета HTTP Геокодер от Яндекса. Что-то около 25000 запросов в месяц бесплатно. Ты отправляешь запрос с широтой и долготой, а сервис тебе населенный пункт (район, улица и т.д.).
Ссылка на сервис:
https://yandex.ru/maps-api/products/geocoder-api
Подключить его не сложно (документация хорошая).

Приведу пример запроса:

PARAMS = {
        "apikey":"ваш api key",
        "format":"json",
        "lang":"ru_RU",
        "kind":"locality",
        "geocode": "долгота, широта"
    }

    #отправляем запрос по адресу геокодера.
    try:
        r = requests.get(url="https://geocode-maps.yandex.ru/1.x/", params=PARAMS)
        #получаем данные
        json_data = r.json()
        #вытаскиваем из всего пришедшего json именно строку с полным адресом.
        address_str = json_data["response"]["GeoObjectCollection"]["featureMember"][0]["GeoObject"]["metaDataProperty"]["GeocoderMetaData"]["AddressDetails"]["Country"]["AddressLine"]
        #возвращаем полученный адрес
        return address_str
    except Exception as e:
        logger2.error(e, exc_info=True)
        #если не смогли, то возвращаем ошибку
        return "error"

Поменяйте только ваш apikey и широту с долготой. Запрос вернет населенный пункт по заданным данным (долгота и широта).

Ссылка на моего бота:
http://t.me/drinking_buddy_2025_bot

Спасибо за внимание

-1

walker

6 фев в 06:106.6K

Яндекс.Музыка заблокировала доступ к сервису на уровне аккаунта. Уже 3 месяца поддержка “разбирается”

С ноября у меня полностью заблокирован доступ к Яндекс.Музыке на уровне аккаунта (bearded-rocker@yandex.ru). Не отдельный девайс, не браузер, не приложение — аккаунт целиком.

TL;DR

Я использую официальный API Яндекс.Музыки
В какой-то момент доступ к Яндекс.Музыке для моего аккаунта был молча заблокирован
Блокировка воспроизводится во всех клиентах: веб, мобильные приложения, устройства
Смена токенов, переустановка приложений, другие устройства — не помогает
В поддержке заведены тикеты ещё с ноября
Прошло больше 4 месяцев — доступа нет, решения нет

Предыстория

Осенью я начал пользоваться Яндекс.Музыкой и колонкой с Алисой. Чтобы не терять годы истории из Spotify, я написал небольшой сервис, который синхронизирует мои плейлисты и треки через неофициальный API Яндекс.Сервис какое-то время нормально работал, после чего доступ к Яндекс.Музыке для моего аккаунта внезапно пропал полностью.

Симптомы выглядят так:

Яндекс.Музыка не работает нигде:— веб— iOS / Android— устройства с Алисой
Это не связано с VPN, IP или устройством
Это не выглядит как клиентская ошибка
Это выглядит как account-level блокировка внутри сервиса
в Браузере получаю ответ (в dev tools):

{ "name": "forbidden", "message": "403 Forbidden: "{"name":"API access restricted","message":""}"", "requestId": "99f13438-a1c9-43a7-9d7d-7de00bd3ea49.1"}

Яндекс.Музыка заблокировала доступ к сервису на уровне аккаунта. Уже 3 месяца поддержка “разбирается”

Я сразу обратился в поддержку Яндекс.Музыки. После стандартных проверок они подтвердили, что проблема не на моей стороне, и завели тикет “на инженеров”.

На сегодняшний день:

есть два тикета, заведённых ещё в ноябре: 25103113405032668, 25121613434183682
каждый новый оператор начинает диалог заново
снова предлагается “обновить браузер / переустановить приложение”
затем снова: «да, мы видим проблему, инженеры занимаются»

Я не прошу ничего экстраординарного:

Восстановить доступ к Яндекс.Музыке для моего аккаунта bearded-rocker@yandex.ru, я плачу за Plus, Алису-Pro и хочу пользоваться этими сервисами.

Сейчас же ситуация выглядит так:

платный сервис недоступен
тикеты “живы”, но без движения
сроков, статуса и ответственного нет

@yandex please help 🙏

Orenlab

3 фев в 17:079.1K

Open source * Python * Алгоритмы *

Копипаста в Python редко выглядит как копипаста

В Python-проектах дублирование кода почти никогда не выглядит как «один файл скопировали в другой». Чаще это повторяющиеся структуры, контрольные потоки и оркестрационная логика, которые со временем начинают незаметно расползаться по коду.

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

Я хочу рассказать про CodeClone — инструмент, который я написал для поиска именно такого дублирования. Он не сравнивает строки и токены, а работает на уровне **нормализованного Python AST и графов управления потоком (CFG).

Почему текстовые clone-detectors не работают

Большинство инструментов ищут дублирование через строки, токены или поверхностное сравнение AST. Это отлично ловит copy-paste, но почти бесполезно, когда код:

переименован,
отформатирован по-другому,
слегка отрефакторен,
но реализует один и тот же сценарий.

В реальных проектах это часто:

одинаковые цепочки валидации,
повторяющиеся request/handler пайплайны,
скопированная оркестрационная логика,
похожие try/except или match/case конструкции.

Идея: сравнивать структуру, а не текст

В CodeClone я пошёл другим путём:

Код парсится в Python AST.
AST нормализуется (имена, константы, аннотации убираются).
Для каждой функции строится Control Flow Graph.
Сравнивается структура CFG, а не исходный код.

Важно: CFG здесь — структурная абстракция, а не модель выполнения. Цель — найти повторяющиеся архитектурные решения, а не доказать семантическую эквивалентность.

Что именно ищется

Функциональные клоны (Type-2)

Функции и методы с одинаковой структурой управления:
if/else, циклы, try/except, with, match/case (Python 3.10+).
Инструмент устойчив к переименованию, форматированию и type hints.

Блочные клоны (Type-3-lite)

Повторяющиеся блоки внутри функций: guard-clauses, проверки, orchestration-фрагменты. Используется скользящее окно по CFG-нормализованным инструкциям с жёсткими фильтрами, чтобы снизить шум.

Почему инструмент намеренно консервативный

Один из принципов проекта:

Лучше пропустить клон, чем показать ложный.

CodeClone не использует ML, вероятностные коэффициенты или эвристические скоринги.
Если клон найден — его можно объяснить и воспроизвести. Это важно при использовании в CI.

Baseline и CI

В живых проектах дубликаты уже есть, поэтому CodeClone работает в baseline-режиме:

codeclone . --update-baseline

Baseline коммитится в репозиторий, а в CI используется:

codeclone . --fail-on-new

Существующие дубликаты допускаются, новые — запрещены.
Это работает как архитектурный регресс-чек.

Про Python-версии

AST в Python не полностью стабилен между версиями интерпретатора. Поэтому версия Python фиксируется в baseline и должна совпадать при проверке. Это сделано ради детерминизма и честности результатов.

Итог

CodeClone не заменяет линтеры или type-checkers. Он полезен, если проект живёт долго, код растёт, и хочется вовремя замечать архитектурное дублирование, а не разбираться с его последствиями позже.

Исходники

GitHub: https://github.com/orenlab/codeclone
PyPI: https://pypi.org/project/codeclone/

Open source * Системное администрирование * Работа с видео * Python *

3 фев в 04:215.7K

Открытый проект 8mb.local — Self‑Hosted GPU Video Compressor умеет сжимать видео любых размеров в десятки раз. Нужный размер пользователь выбирает сам, а компрессор подстроится. По возможности сохраняет качество. Можно выбрать кодек, битрейт и даже обрезать видос во встроенном редакторе. Всё работает локально.

Kisel_n

2 фев в 19:407.9K

Python * Искусственный интеллект

Clawdbot: когда обезьяне дали гранату 🤡

Совсем недавно Clawdbot хайпанул. И тут такое началось... Это не цирк, это хуже.
Добрый дядя из гайда советует прокинуть туннель через ngrok или развернуть это дело на VPS с открытым портом.

Итог: любой школьник находит ваш IP или ngrok-адрес и получает RCE (удаленное выполнение команд) от вашего имени.

Судя по последним новостям агенты и сами не против опубликовать куда нибудь ваши тонны. Так, между делом.

Какой-то цифровой эксгибиционизм. Отберите у них Докер, пока не поздно.

Python * Машинное обучение * Учебный процесс в ITИскусственный интеллектБудущее здесь

2 фев в 10:495.7K

Вышел Nanobot: сверхлёгкая версия Clawdbot (сейчас Openclaw), которая на 99% проще и позволяет запустить ИИ‑помощника менее чем за минуту. Clawdbot кажется слишком сложным, а в Nanobot разберётся даже новичок. Весь движок умещается всего в ~4000 строк кода на Python, тогда как Clawdbot это огромный монстр на 400 000 строк. Nanobot запускается за минуту и готов помогать вам в повседневных задачах, включая анализ рынка в реальном времени: непрерывный мониторинг и сбор аналитики, разработку ПО, помощь в комплексных проектах, управление делами и оптимизация рабочего времени, персональный помощник по знаниям.

Тестирование IT-систем * Python * Java * Тестирование веб-сервисов * Исследования и прогнозы в IT *

2 фев в 07:593.8K

Как оставаться релевантным на рынке QA/AQA/SDET в 2026: опыт, харды, софты, ответы

Последнее время всё чаще слышу вопросы про состояние рынка.
Многие говорят, что рынок «умер», вакансий стало меньше, а требования выросли настолько, что найти работу почти нереально.

Часто это выглядит так: человек активно откликается, ходит на собеседования, делает тестовые задания, общается с рекрутерами.
А на выходе получает либо отказы без конкретных причин, либо формулировки вроде «вы хороший специалист, но нам нужен немного другой профиль».

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

Я регулярно общаюсь с QA, AQA и SDET, которые находятся в активном поиске, и сам продолжаю проходить собеседования, чтобы понимать, как именно сейчас устроен процесс найма.
И вот что я понял из всех историй: сегодня выигрывает не самый наглый кандидат (как было раньше), а тот, кто хорошо понимает свой опыт и умеет его объяснять.

Что изменилось

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

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

Это не «заговор рынка», а естественная фильтрация. Когда выбор кандидатов большой, требования становятся строже.

Почему в этом есть плюсы

Жесткий рынок хорошо отсеивает слабые места. Причем чаще всего самые базовые.

На собеседованиях у ребят регулярно всплывают одни и те же проблемы:

человек говорит, что строил фреймворк, но не может связно объяснить архитектуру;
упоминает автотесты, но не понимает, почему был выбран конкретный стек;
рассказывает про CI, но путается в вопросах стабильности;
заявляет ответственность за качество, но не может описать процессы и зоны ответственности.

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

Как сейчас смотрят на опыт

На интервью все меньше внимания уделяется формальным строчкам в резюме и все больше мышлению.

Интервьюеру важно понять:

Почему было принято именно такое решение;
Какие были трудности;
Как проблемы диагностировали;
Какие выводы сделали.

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

Поэтому сейчас важна не красивая история, а осознанное понимание своего опыта.

Что с этим делать

Минимальный практический набор:

Разложить свой опыт по зонам - архитектура, API, UI, CI/CD, процессы, инциденты.
Подготовить ответы в формате «проблема - решение - результат - выводы». (Для шарящих - по STAR)
Прогнать опыт через уточняющие вопросы и проверить, где ответы выглядят слабо или непоследовательно.
Упаковать резюме как набор конкретных ответов - что улучшал, что оптимизировал, за что отвечал + быть готовым это подтвердить.

Вывод

Рынок действительно стал сложнее.
Но именно поэтому он стал более комфортным для тех, кто держит фокус на релевантности, понимает свой опыт и готовится к проверке.

Если относиться к поиску работы как к инженерной задаче, жесткий рынок перестает быть проблемой и становится рабочей средой.

Ну а всем нуждающимся желаю скорее обрести себя на сегодняшнем рынке! Готов подискутировать на смежные темы в комментариях)

-3

Python * Учебный процесс в ITКарьера в IT-индустрииОблачные сервисы *

31 янв в 04:068.4K

Открытый учебный проект 30 Days of Python помогает освоить синтаксис и концепции языка программирования за месяц. Там есть основная база Python от настройки окружения до мощного ООП, организации кода и паттернов проектирования. Каждый день — новая тема. После каждого урока есть десятки вопросов для самопроверки и упражнений для повторения. При этом каждый следующий урок опирается на предыдущий.

Информационная безопасность * Системное администрирование * Python * Тестирование веб-сервисов * Облачные сервисы *

27 янв в 06:395.4K

Представлен легковесный инструмент Crawlee, который может спарсить информацию с сайтов, соцсетей и других ресурсов, а также обходит защиту от ботов. Может скачать аудио, видео, изображения, метаданные, документы и прочие нужные файлы. Скрипты решения написаны на Python, имитирует поведение человека на сайтах, в соцсетях и других ресурсах. Инструмент поддерживает мультизадачность и не теряет при этом скорость. Можно собирать несколько видов данных одновременно. Работает полностью локально.

El_Gato_Grande

23 янв в 10:005.7K

Блог компании SelectelPython * Программирование * Учебный процесс в ITЧитальный зал

Подборка инструкций по Python для начинающих специалистов

Привет, Хабр! Вот и наступила пятница, а значит, пришло время очередной подборки материалов для тех, кто решился взяться за изучение Python. Сегодня у нас несколько базовых инструкций, бесплатный курс и небольшой квиз.

Как работать с PostgreSQL в Python. Эта статья-шпаргалка научит работать с модулем psycopg2, чтобы немного упростить себе жизнь при администрировании PostgreSQL.
Рукописный редактор на Python: инструкция для тех, кто хочет «рисовать» код. Создадим виртуальный лист, на котором можно набросать код от руки — и он будет исполняться!
Как создать голосового помощника на Python. С помощью простых инструментов и библиотек разработаем голосового помощника на Python, сделав его полезным и удобным в повседневной жизни.
Квиз: хорошо ли вы разбираетесь в Python? Тест на владение синтаксисом Python. Позволит оценить свои знания и отыскать пробелы.
Изучаем Python: теория, практика, настройка инструментов. Да, это подборка в подборке. Внутри несколько материалов, все доступно бесплатно. Для тех, кто хочет научиться не только писать код, но и запускать его в облаке, внутри курса спрятан промо-код на услуги Selectel.