Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Начать программировать на Python бывает непросто: в интернете много материалов, но понять, что нужно, а что не очень — трудно. Новички тратят время на уроки со сложной теорией, хватаются за все подряд, а потом не понимают, как применить полученные знания на практике.
На самом деле, для начала достаточно разобраться в основах и сосредоточиться на тех инструментах, которые активно применяются в разработке. Собрали для вас подборку таких инструментов, а на Хабр Карьере — полезные учебные программы по каждому из них:
— Django. Фреймворк для быстрой разработки веб-приложений с готовой админкой и базой данных.
— Flask. Микрофреймворк, который дает полный контроль над выбором инструментов и структурой проекта.
— FastAPI. Фреймворк для создания API, основанный на базе стандартных библиотек Python и асинхронности.
— PostgreSQL. Реляционная база данных для хранения данных.
— Gunicorn. Стабильный WSGI-сервер, который помогает запускать Python-приложения.
Как понять, что ваш интернет-магазин вот-вот сломается: триггеры и решения для сайтов на Magento
Привет! Это Дмитрий Абакумов magento-разработчик в Далее, и Максим Бровко, тимлид в Далее.
Мы собрали 5 типичных симптомов, которые сигнализируют, что система уже нестабильна — на примере Magento, популярной CMS в сфере e-com.
В первую очередь скажем, что на Magento работают крупные бренды по всему миру. Она гибкая, масштабируемая, с богатой экосистемой. Однако без регулярных обновлений, контроля и DevOps-поддержки любой проект начинает замедляться, сбоить, а со временем — ломаться. Сигналы появляются заранее: сначала падает скорость, потом checkout, потом весь сайт.
Сигнал 1: падение скорости при большом трафике — во время акций и распродаж
Что проверить
Узкие места в БД: тяжелые SELECT, отсутствие индексов.
Дублирующиеся или вложенные вызовы блоков в Magento layout.
Как ведет себя cron и очередь задач.
Используется ли Varnish для FPC и/или Redis для общего кеша.
Как чинить
Настроить загрузку тяжелых блоков после рендера страницы — через AJAX.
Минимизировать around-плагины и preference (перезаписей классов), отдавать предпочтение before/after-плагинам и observer.
Покрывать фиксы хотя бы базовыми unit/integration-тестами.
Настроить dev → stage → prod, релизный процесс с changelog.
Ввести code style, практику ревью и договоренности внутри команды.
Сигнал 5: CMS или модули устарели, все «на костылях» и никто не решается трогать
Что проверить
Версии ядра Magento и зависимостей.
Нет ли deprecated-библиотек, особенно JS.
Насколько кастомно переопределены шаблоны и классы.
Есть ли onboarding-документация, описание архитектуры, миграций, cron.
Как чинить
Если кастомный код внесен прямо в ядро Magento, то его нужно вынести в отдельные модули.
Сравнить архитектуру с best practices Magento и рекомендациями вендоров.
Написать README и настроить автоматизацию — Docker, Ansible.
Запланировать регулярные апдейты проекта.
Если у вас совпадают 3+ пункта — пора на техаудит
Magento почти всегда подает сигналы заранее: снижается скорость, растет количество багов, страдает checkout. Если таких симптомов становится много — пора остановиться и разобраться, что происходит внутри.
Что делать
Использовать метрики: PageSpeed, TTFB, логи ошибок.
Провести аудит: кеш, модули, layout, архитектура, DevOps.
Найти узкие места и критичные зависимости.
Выделить приоритеты по улучшениям и составить roadmap по рефакторингу.
Во что я верю, когда меня спрашивают про карьеру в IT
Время сейчас такое... Мой знакомый разработчик (20 лет в профессии) года три назад еще и представить себе не мог, что будет целый год искать работу и не получит ни одного офера. Ну ок, там возраст, но он далеко не один в такой ситуации. Я так давно уже не верю в то, что кто-то обо мне позаботится, кроме самого себя.
Похоже на то, что в следующие 3-4 года в айти произойдут большие изменения. Когда меня спрашивают, что сделать и как к этому подготовиться, в ответ я могу сказать лишь то, во что верю сам.
1. Я верю в то, что неизменно на протяжении тысяч лет, люди по-прежнему будут кушать, какать, любить, болеть, чему-то учиться и чего-то бояться.
2. Бизнесы будут бороться с конкурентами, изо всех сил хвататься за возможность завоевать новые рынки, и максимально пытаться отжимать из человека все за зп.
3. Проблемы не исчезают, они усложняются. Спрос на решения реальных проблем (безопасность, облачная инфраструктура, данные, плюс все человеческие потребности, хотелки, страхи) будет расти.
4. Довольно долго еще не будет одного ИИ-решения для всего, условного GPT-бога или GPT-джина.
5. Контроль важнее стабильности. Работа в найме это иллюзия безопасности, которую может разрушить один мейл от HR. Участие во владении продуктом это владение инструментом создания ценности, а не зависимость от чужого решения о твоей ценности.
6. Рынок вознаграждает тех, кто решает, а не ждет. Пока большинство парализовано неопределенностью и ждет стабилизации, появляются ниши и возможности для тех, кто действует сейчас.
7. Удача это подготовка, встретившая возможность. Невозможно предсказать, какой именно продукт выстрелит, но можно увеличить количество попыток и качество каждой из них. Чем больше ставок ты делаешь, тем выше шанс попасть в правильное время и спрос.
8. Ставка это не хобби после работы, и не пет-проект между кофейней и спортзалом. Ставка это когда ты фигачишь так, как будто от этого зависит все твое будущее, пусть даже только пару-тройку дополнительных часов в день.
9. Человеку в одиночку гораздо сложнее построить устойчивый дом или компанию, чем команде людей.
10. Выбирай команду не только по целям, но и по ценностям.
Я продолжаю создавать удобные продукты для людей и бизнесов, пытаясь попасть в хороший спрос и время, удачное для взлета этих продуктов. Кто со мной?
Разбираемся как принимать звонки в браузере. Основы WebRTC\SIP\RTP.
Во многих коммуникационных продуктах возникает потребность работы с голосом. В этой серии постов разберемся как организовать прием звонков непосредственно из вашего web приложения. Какие есть варианты передачи звукового потока и какая может быть архитектура backend приложения, обеспечивающего его работу.
Начнем с самой простой в реализации схемы, в которой передача голоса осуществляется напрямую между браузером пользователя, открывшего ваше web приложение и серверами провайдера "виртуальной телефонии"(aka "виртуальная атс" ). При этом вся мета информация о поступившем входящем звонке и событиях всего жизненного цикла звонка принимает ваш backend. У разных провайдеров телефонии набор событий и строения api может отличаться, но общая схема работы схожа.
Разберем основную схему организации передачи голоса. Браузер по сути работает как SIP‑телефон: сигнализация через WebSocket, медиа — по RTP.
Упрощенно схему работы WebRTC/SIP можно разделить на "регистрацию", "звонок" и "завершение":
1. Регистрация в сети
Оператор открывает страницу в браузере.
Браузер отправляет SIP REGISTER на SIP‑сервер (WebSocket/TLS).
SIP‑сервер отвечает 200 OK.
В интерфейсе показывается «Вы в сети» — оператор готов к звонкам.
2. Звонок
SIP‑сервер отправляет SIP INVITE в браузер.
Браузер показывает уведомление «Входящий».
Оператор нажимает «Принять».
Браузер запрашивает доступ к микрофону (getUserMedia) — внутреннее действие.
Браузер отправляет SIP 200 OK + SDP на SIP‑сервер.
SIP‑сервер отправляет SIP ACK в браузер.
SIP‑сервер даёт команду RTP/SRTP‑шлюзу установить медиа‑сессию.
Медиа (RTP/SRTP по UDP) передаётся между браузером и RTP‑шлюзом.
Начинается разговор.
3. Завершение звонка
Оператор нажимает «Завершить».
Браузер отправляет SIP BYE на SIP‑сервер.
SIP‑сервер отвечает 200 OK.
Передача RTP/SRTP прекращается.
Если тема будет интересна, то далее обсудим схему работы backend'а и варианты развития общей схемы передачи голоса с плюсами, минусами и ограничениями.
В своем канале в Telegram и канале в Max о разработке в стартапах рассказываю еще больше интересного и делюсь опытом, заходите, буду рад!
⚠️ Java продолжает готовиться к удалению finalize()
В рамках JDK 27 у ThreadPoolExecutor-а, очень популярного API в Java, будет удалён метод finalize(). Несмотря на то, что в силу dynamic dispatch вызов метода finalize() всё равно будет транслирован в Object, данное изменение не source level compatible.
А все потому, что у Object.finalize() сигнатура содержит throws Throwable, в то время как ThreadPoolExecutor.finalize() — нет. Пока метод был в ThreadPoolExecutor, компилятору было ок. Как только его удалят, вызов super.finalize() начнет резолвиться в Object.finalize(), и тогда прилетит “unreported exception Throwable”.
Вот это кстати довольно редкий пример того, что имзенение может быть binary level compatible, но не source level compatible.
Например:
class MyPool extends ThreadPoolExecutor {
@Override
protected void finalize() {
super.finalize(); // JDK 27: теперь это Object.finalize() throws Throwable
}
}
Как избежать?
поискать и удалить любые finalize() / super.finalize() (и вообще любые авто-cleanup через финализацию)
управлять жизненным циклом executor’ов явно: shutdown()/awaitTermination() или просто close() в try-with-resources (да, ExecutorService — AutoCloseable)
Spring АйО рекомендует не использовать finalize() в целом, но если подобного рода хук нужен, то лучше использовать Java Cleaner API. С его помощью нельзя "случайно" воскресить объект, сломать integrity объекта или т.п.
Ждем JDK 27 🫠
Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм — Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано.
Не секрет, что про написание кода AI-агентами в автономном режиме (я буду пользоваться термином vibe coding, хотя он не вполне точен) сейчас прям нам вещают из каждого динамика.
С другой стороны, я довольно много использую AI для написания кода, и мои ощущения - «иногда работает неплохо, но надо проверять и высок риск, что в код пролезет какая-то дичь». Т.е. это сильно расходится с историями из интернета. Я внезапно смог четко сформулировать для себя, почему так и когда это работает, а когда нет.
Есть два типа программистов. Первые усиленно пользуются отладчиком, пишут и запускают 100500 тестов и все равно их код часто сбоит, когда что-то идет не по happy path сценарию. Вторые думают, идут гулять с собакой, возвращаются и пишут в разы меньше кода, который работает намного надежнее. На самом деле я, конечно же, идеализирую, и все мы находимся между типом 1 и типом 2, просто кто-то чуть ближе к одному, а кто-то к другому полюсу.
Но в чем принципиальная разница между этими типами? У типа 1 есть какое-то, часто очень локальное предположение о том, как должен работать код, он действует по принципу monkey see, monkey do. Второй пытается построить в голове модель того модуля, который он реализует, и дальше уже, имея модель, овеществляет ее в коде. Второе, как правило, быстрее и надежнее, но на порядок сложнее и требует глубокого понимания всех вовлеченных в процесс элементов.
При этом в IT есть масса задач, которые решаются первым способом, не сильно подготовленными инженерами. Будем честны, последние лет 15-20 первый подход изрядно доминирует в commodity IT, и этому есть объективные причины. Это накладывает отпечаток на инструментарий, культуру, построение SDLC процессов и т.п. (некоторые менеджеры просто не верят, что есть инженеры, которые без тестов и плясок с бубном могут посмотреть на проблему и сказать «вот так делайте»).
Возвращаясь к vibe coding - AI-агент это чистый тип 1. Модель системы и процессов в ней у него не глубже, чем память у золотой рыбки, потому что он оптимизируется под внешний feedback, а не под внутренние инварианты. Он, конечно, пытается что-то документировать, и ему пытаются писать требования, но все это работает довольно тяжело. Одна из причин в том, что инженер (хороший) не только машина для нажимания кнопок, но и источник множества мельчайших, но критически важных функциональных и нефункциональных требований, многие из которых ни бизнес аналитик, ни product owner прописать не могут (тут я в очередной раз сошлюсь на Polanyi's paradox - https://en.wikipedia.org/wiki/Polanyi%27s_paradox).
Это обстоятельство далеко не всегда имеет смысл и не всегда важно. Если вы делаете сайт для записи в барбершоп и вам надо показать список барберов, потом список слотов и потом сделать кнопку book, то строить глубокую модель системы смысла не имеет. Если вы делаете софт для электронной педали газа в автомобиле, то помимо тестов, хорошо бы точно понимать, как что работает и для чего каждая строчка кода и каждая из переменных. Между этими двумя примерами, разумеется, есть широкое поле для обсуждения.
Возвращаясь к AI-агентам - по идее искусство работы с ними заключается в понимании того, где ваша задача находится относительно этой системы координат, и в выдаче агенту задания нужного размера и нужной сложности. Где-то можно доверить делать большой кусок, где-то не более одного небольшого метода, а где-то вообще надо руками написать код. Неожиданное следствие для меня как динозавра, больше полагающегося на понимание кода, чем на тесты - даже если тесты не важны мне, все равно стоит их завести в какой-то мере для AI-агентов, если я хочу ими пользоваться для ускорения разработки.
Надо только правильно их таргетировать - для каких-то кусков они имеют смысл, а для каких-то просто трата времени.
Любой руководитель в распределенной команде сталкивался с ситуациями, когда команда начинает гореть от созвонов. Спринт задачами набили, оценили, а потом половину не сделали. Из-за чего? Не попали в оценки. Были влеты..
А еще была куча общих встреч, ретро, планнингов, скрам-баннингов и интерраптов, которые на доске и в таймшите не увидишь.
Инженеры так не любят созвоны, потому что у них неосязаемый импакт и definition of done. Они мыслят задачами, мерж-реквестами, зелеными тестами, чем-то с измеримым результатом. Сел за задачу, вник и сделал. КПД в идеальных условиях напоминает воркера. В очередь пришла задача — он ее обработал и закрыл, ждет следующую. В перерывах гладит кота или пузо.
Когда инженер сидит на звонках, которые его напрямую не касаются, его пропускная способность падает из-за ложных сигналов. Он не может нормально параллельно работать. Надо либо час вникать, либо мозг выключается в мемы, либо на встречу в принципе забивают. Многие созвоны вообще не для инженеров. Они для менеджеров.
Для внеплановых статусов менеджер не всегда заранее знает, кто ему по факту нужен, и зовет «на всякий». На созвонах, кроме ведущего и ЛПР, участники в принципе нужны подстраховать. Вася может понадобиться. А может и не понадобиться. И опять сидит Вася без камеры, без микрофона и грустит. Ждет, когда все закончится, чтобы вспоминать, на чем он там остановился.
На моей практике лишние звонки исходят от консервативных слабых процессов и выученной беспомощности. Есть на проекте карго-культ аджайла и плохая база оперативных знаний. День забит статусами и повторами одной и той же информации для разных людей.
Кто поможет создать правильный шумовой барьер и дать команде работать, при этом отдавая в проектный офис нужную информацию? Как по мне, это не обязательная боль инженера. Побороть проблему — роль хорошего лида.
Урон от звонков надо вбирать в себя лиду. Его обязанность — знать контекст по верхам о проблемах и задачах вверенной команды. Отстаивать их интересы, обрабатывать обратную связь. Таков путь, отделяющий лида от сеньора-помидора.
Лиду надо собирать дашборды, таблицы, фильтры, регламенты, схемы. Запросы на оперативную информацию не должны отнимать ресурсов. Все по полочкам: база знаний, закладки, конфля, raycast шорткаты, ИИ-агента с MCP натравить на Confluence и Jira (если ИБ по шапке не даст). Надо и свой ресурс беречь и дать просящему удочку вместо рыбы.
От лишних звонков можно отказываться. Без конфронтаций, просто фильтровать: «А зачем? Вот все ответы на вопросы». Либо можно договориться многие задачи сделать асинхронно. Таска в джире с исполнителем и сроком и поехали.
Проектам нужна карта компетенций. Для тех ситуаций, где нужно глубже вникнуть в предметную область, это ок — привлечь инженера вместо лида. Важно знать, какого. Классический мем: девять женщин не могут родить ребенка за месяц. С этим стереотипом «больше-лучше» карта компетенций помогает бороться.
Звонок на час — плохой дефолт. 45 минут — уже лучше. 30 минут — еще лучше. 15 можно не ставить, есть мессенджер и почта.
Звонки должны ставиться по календарю. Вызванивать минута в минуту — моветон хотя бы потому, что есть правда неотложные ситуации. Но не все звонки — неотложные.
У звонков должны быть повестки. Приглашенные должны иметь возможность понимать, о чем пойдет речь. В идеале, нужна ссылка на доки или задачи. Без этого участники идут на звонок вслепую и тратят время, чтобы понять, что от них хотят.
Побуду адвокатом дьявола. На некоторые звонки команду лидам брать надо. Так можно узнать полезную информацию с полей. Ребята могут раскрыться, вовлечься. Вполне смогут затащить какой-то каверзный проект и унести его в перфоманс ревью.
В общем-то из поста у меня нет цели делать вывод, что звонки — зло. Хотим удаленку, значит потерпим общение в зуме. Как и любой другой канал коммуникации, звонок — это инструмент. У него есть области применения, хорошие практики.
Зло — звонки не оптимизировать. А инженера с его очередью лучше оставить в цикле и не засорять эфир.
Трамписты решили сделать королевский подарок многополярному миру в лице Индии, Китая и в меньшей степени России и Ирану с помощью остановки программы рабочих H-1 виз. Поясню свою мысль (я в курсе, что половина людей комментирует по заголовку, а 75% не читают дальше первого абзаца, но тем не менее):
Я тертый калач и не идеализирую получателей рабочих H-1 виз (сам был таким в 1991 году). Большинство из них так же мухлюет в резюме как и местные, и не являются светочами технологической мудрости или трудовой этики. Кроме этого время ожидания гринкарты по labor certification сидя на H-1 визе перешло любые разумные пределы: в середине 1990-х оно было 3 года, сейчас некоторые больше 10 лет ждут. Я уже не говорю что H-1 визы разбираются аутсорсерами, и даже большим компаниям остается таких виз с гулькин нос. Короче сейчас большинство предприимчивых технарей старается сделать O-1 (особые способности) и некоторые L-1 (перевод из иностранного отделения компании в американское).
Тем не менее для меня очевидно, что полный бан на такие визы - это выстрел Америки себе в ногу и начало фундаментального изменения отношения ученых и инженеров других стран к эмиграции в Америку. Они будут оставаться на родине и перестанут мечтать про прекрасное далеко. Так как прекрасное далеко станет фундаментально недоступно, они начнут делать не на отцепись в других странах. Уйдет мысль "то что я тут в Индии/Китае/России/Иране лабаю - это так, временно, а вот уеду в Америку - там буду работать на совесть по гамбургскому счету. Буду слать фотки себя в кампусе Гугла/Микрософта, друзья детства будут мне завидовать, а бабушка всхлопывать ладошами при виде моего дома в Редмунде или Купертино и говорить "какое богатство!"
Улучшится ли от этого уровень американских студентов, которые заместят иностранцев и с помощью ИИ будут показывать чудеса производительности и качества на рабочем месте? Есть конечно масса способных американских студентов. Но есть и масса неспособных. Может даже Вэнс притащит в Силикон-Вэлли молодежь из гор Аппалач и других неблагополучных районов своего детства и они вместо наркомании и сидения на пособиях станут писать код или делать дизайн. Как говорила Верочка из "Служебного романа": "Можно и зайца научить курить". А вы как думаете?
Спустя почти год работы мой PR приняли в ядро Joomla!
[Тут должна быть победная пляска] Год назад у моих клиентов возникла необходимость во вставке видео в кастомные поля материалов в раздел портфолио. Я начал делать и увидел, что именно стандартное пользовательское поле Media не умеет вставлять в поле ничего, кроме изображений, хотя поле Joomla Form MediaField умеет выбирать и документы (pdf и иже), аудио, видео и даже папки. Я начал работу над тем, чтобы добавить этот функционал в ядро и очень надеялся успеть к Joomla 5.3, которая выходила в апреле. В целом все сделал, сделал PR 25 февраля 2025 года, но PR не приняли, сказав, что это шибко новый функционал и ему будет хорошо в Joomla 6.0.0. Клиентам пришлось использовать медиа-менеджер от JCE, а PR отправился ждать релиза 6.0.0, который выходил осенью. К слову сказать, эта пауза была полезна для него, так как летом, уже неспешно я получал советы по улучшению и в июле всё точно было готово.
Релизный цикл Joomla состоит из нескольких этапов: сначала выходят alpha-версии (до 3х штук), где просто фиксируются накопленные изменения, потом beta, где наступает feature freeze - заморозка новых функций, их нельзя уже добавлять. Дальше только отладка и правки существующих новшеств. У каждого релиза есть 2 релиз-менеджера.
В работе над PR мне помогал все это время Брайан Тиман - ко-фаундер Joomla. К концу июля все было готово, проверено, PR имел 2 необходимых независимых теста. Ждём беты.
Дата беты приходилась на понедельник. Где-то в пятницу днём я отписался в PR и получил совет написать релиз+менеджерам. Как-то удалось найти их в Mattermost, где обитает международное сообщество, но пятница и выходные, а все ж волонтеры и не на зарплате... Моё сообщение прочитали после релиза беты... Сказали, что не были в курсе моего PR (ожидаемо, их около 200-250 все время открытых). И сказали, что поезд ушёл, хоть и so sorry. Зато будет хорошо увидеть PR на тестах в Pizza, Bugz and Fun и вообще welcome в 6.1.
После выхода 6.0.0 меняются релиз-менеджеры. Мы списались: да, все хорошо, но нужно кое-что подправить. Тут конец года и закрытие дедлайнов, потом Новый год и весь январь никто толком не работает. Beta для 6.1 выходит 17 февраля. Последняя alpha недели за 3 до этого.
Незадолго до выхода альфы я-таки получаю сообщение, что реализуемый функционал сделан не по "Joomla way" и если код в ядре, то этот код является учебным пособием по тому, как ядро использовать. Резонно. А ещё у релиз-менеджера есть собственные наработки и экспертиза в этой теме и свой медиа-менеджер, в котором он тоже прошел огонь, воду и медные трубы. Согласно Joomla way мне нужно было разделить одно мега-крутое поле на 4 отдельных (картинки, аудио, видео и документы). Я подумал, что требуется сделать 4 плагина вместо одного и сказал, что не успею. Мне ответили, что beta is more important for us и время ещё есть, что мне подскажут и 4 плагина делать не нужно.
Пока суть да дело - время идёт. У меня тоже работа, трое детей, карантины, уроки... Но добить этот PR уже стало делом принципа. Я нашел как нужно было делать, принял несколько правок и пожеланий, потом фиксы code style. Сегодня с утра был последний коммит. Сегодня вечером, 11 февраля 2026 года, PR наконец-то смержен в ядро Joomla.
Эта работа научила меня очень многому. 170 комментариев в conversation на GitHub, несколько отдельных переписок, 1 год на разработку и внедрение простой в целом фичи, "звоночек" в голове: "не забыть, успеть, сделать, найти"...
Сегодня я поднимаю кружку пенного за этот небольшой в целом PR, за этот прошедший год, за Joomla и за Open Source.
Может показаться, что начинать изучать программирование поздно — все вакантные места уже заняты другими разработчиками. Но это не так: толковые специалисты нужны всегда и везде, поэтому начать никогда не поздно.
Если не знаете какой язык выбрать, присмотритесь к одному из самых популярных — к C++. Он хорошо подходит для системного и прикладного программного обеспечения, игровых движков, финансовых технологий, высоконагруженных сервисов, встраиваемых систем и всего, где важна скорость и эффективность.
Для вашего удобства мы собрали учебные программы по C++ в одном месте — на Хабр Карьере, а сегодня предлагаем познакомиться с основными инструментами, которые вам предстоит освоить, чтобы стать опытным разработчиком:
— С++. Основа основ: язык программирования с высокой производительностью.
Открываем быстрый найм на позиции RTL-дизайнера и верификатора в команду Semiconductors. Подать заявку можно до 22 февраля.
Кого ищем:
UVM Verification Engineers (junior/middle/senior) — UVM-окружения, VIP, SVA, регрессии, анализ багов, работа с RTL-командами.
RTL Design Engineers (junior/middle/senior) — разработка сложных ASIC-модулей на Verilog/SystemVerilog.
Как проходит спринт:
Нужно оставить заявку до 22 февраля и пройти HR-скрининг.
Далее техническое и менеджерское интервью.
И вуаля — оффер у вас на руках.
Чем занимается команда: fabless-разработкой микропроцессоров на базе RISC-V с полным циклом создания SoC — от архитектуры и собственного процессорного IP до поставки чипов с системным ПО. Решения используются в серверных, телекоммуникационных и сетевых продуктах, системах хранения данных и клиентских устройствах.
Стек и ожидания:
Verilog/SystemVerilog,
RTL-симуляторы: VCS / Xcelium / Questa,
Linux,
Git,
скрипты для автоматизации: Python / Perl / Tcl / Shell,
Когда мне пришла в голову мысль что я хочу навайбкодить операционку, у меня было смутное представление что полноценным успехом можно будет считать только self-hosted OS, то есть чтоб в ней запускались дев-тулы, можно было поправить исходники, скомпилировать, ребутнуться с новым ядром и все продолжало работать.
Если честно, я не думал что получится, думал в лучшем случае получу что-нибудь что может запустить пару kernel-space процессов которые будут по очереди что-то в UART печатать и все. А оно раз, и получилось… Self-hosting milestone взят!
В Slopix есть: - Простенький шелл - Компилятор Си (и прочие build essentials) - Интерактивный редактор текста с подсветкой синтаксиса для Си
Принципиально ничто не мешает теперь заниматься разработкой слопикса в слопиксе.
Потребовалось 5 weekend sprints. Получилось примерно 45к строк на Си. Узнал много нового про операционки и многому научился в плане coding agents workflows. Ну и тонну удовольствия получил, конечно же!
Автоимпорт при копировании кода — штука настолько приятная и удобная, что без неё уже невозможно представить работу в IDE.
Мы пошли дальше и вслед за умным импортом во время набора кода сделали автоматическую инжекцию бинов при копировании кода!
Теперь при копировании кода Amplicode автоматически добавляет нужную инжекцию бинов. С учётом контекста, @Primary, @Qualifier, дженериков, @Bean-методов, Java и Kotlin — без ручной возни после вставки.
Будет доступно всем пользователям Amplicode, без подписки.
Коллеги, 03.02.2026, три дня назад я провёл вебинар, посвящённый полиглотности СУБД - умению работать с диалектами PostgreSQL, Oracle и Microsoft в контексте импортозамещения.
Меня зовут Жуйков Андрей, и если будет время - буду рад, если посмотрите запись 👀
«Импортозамещение СУБД по-новому: интеллектуальный подход к замене MS SQL и Oracle»
🔹 Установка и первый запуск Digital Q.DataBase • развёртывание Digital Q.DataBase в Docker-контейнере • установка и настройка Digital Q.DataBase на Ubuntu 24.04 • архитектура, ключевые преимущества и типовые сценарии использования в российских компаниях
🔹 Новые возможности Digital Q.DataBase для импортозамещения • инструменты, упрощающие миграцию с MS SQL и Oracle • как сократить риски и сроки перехода без переписывания приложений
🔹 Практика внедрения и реальные кейсы • Владимир Авсеев показал, как система «Босс-Кадровик», изначально заточенная под MS SQL, успешно работает на Digital Q.DataBase • Анастасия Коршунова (отдел разработки) продемонстрировала примеры успешной интеграции Digital Q.DataBase с 1С и Delphi-приложениями
🔹 Ответы на вопросы • практические нюансы миграции и эксплуатации • ответы на вопросы из реальных проектов от разработчиков Digital Q.DataBase и команды «Босс-Кадровик»
Как принять 4 проекта в курирование и не свихнуться?
TL;DR
Руководитель дал 4 новых проекта в архитектурный надзор. Держать всё в голове нереально. Изучил индустриальные практики и подготовил процесс приёмки совместно с Claude Code. Выложил в open-source. Буду рад feedback от вас и ваших агентов.
Как всё началось
Руководитель: "Вот тебе 4 проекта - принимай в работу."
Я: "Окей... А что там?"
Руководитель: "Узнаешь."
Контест:
4 проекта
Где-то есть пересечение функциональности (где именно - неясно)
Команды разные, стек разный, зрелость разная
Держать всё это в голове - бесмысленно
Немного поглядел - стало понятно: нужен системный подход.
Что я сделал
1. Изучил индустриальные практики
Посмотрел, как это делают:
Futurice Project Handover Checklist
TOGAF Architecture Review
Harvard EA Checklist
Практики из книг (Software Architecture in Practice, Building Evolutionary Architectures)
2. Собрал процесс приёмки и аудита
Готовил совместно с Claude Code. Не в чистом виде, конечно с моей конфигурацией (на текущий момент это 3882 строк rules, skills and commands). Безусловно, вычитывал и редактировал.
В Python-проектах дублирование кода почти никогда не выглядит как «один файл скопировали в другой». Чаще это повторяющиеся структуры, контрольные потоки и оркестрационная логика, которые со временем начинают незаметно расползаться по коду.
Формально всё выглядит по-разному: другие имена, другие константы, чуть иной порядок. Но архитектурно — это одно и то же решение, просто размноженное.
Я хочу рассказать про CodeClone — инструмент, который я написал для поиска именно такого дублирования. Он не сравнивает строки и токены, а работает на уровне **нормализованного Python AST и графов управления потоком (CFG).
Почему текстовые clone-detectors не работают
Большинство инструментов ищут дублирование через строки, токены или поверхностное сравнение AST. Это отлично ловит copy-paste, но почти бесполезно, когда код:
Важно: CFG здесь — структурная абстракция, а не модель выполнения. Цель — найти повторяющиеся архитектурные решения, а не доказать семантическую эквивалентность.
Что именно ищется
Функциональные клоны (Type-2)
Функции и методы с одинаковой структурой управления:
Инструмент устойчив к переименованию, форматированию и 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. Он полезен, если проект живёт долго, код растёт, и хочется вовремя замечать архитектурное дублирование, а не разбираться с его последствиями позже.
В любой работе важны не только технические навыки, но и умение договариваться, управлять своим временем и адаптироваться к изменениям: это помогает расти в команде, не бояться ответственности и чувствовать себя уверенно.
А чтобы становиться лучше было проще, мы на Хабр Карьере собрали курсы, которые помогут вам развить надпрофессиональные навыки без скучной теории и далеких от реальности примеров:
