Привет, Хабр! Меня зовут Данила, мне 21 год, и за последние 2,5 года я успел поработать в роли разработчика программного обеспечения для встраиваемых систем — в основном на базе STM32. В этой статье я хочу поделиться тем, как я вообще пришёл в эту сферу, с чего начинал, какие грабли собрал и какие выводы сделал по пути.
Когда-то всё было проще. В достопамятные двухтысячные годы джунов и в самом деле нанимали. Не спрашивали о «релевантном опыте», не требовали ссылки на боевые проекты и не строили сложных лабиринтов из HR-интервью, технических сессий, тестовых заданий и многоступенчатых собеседований. Но прошло 15–20 лет — и всё изменилось до неузнаваемости. Новички (стажёры и джуны) теперь бесправны и даже подозрительны.
У нас были две сотни брокеров, шесть тысяч топиков, клиенты на четырех языках программирования, миллионы сообщений в секунду и целое море различных паттернов использования Kafka. А также жесткие требования по latency, тонна SLA и желание сделать гибкую систему аутентификации и авторизации для сервисов. Не то, чтобы все это было категорически необходимо для начала этой истории, но если уж начал рассказывать про асинхронные взаимодействия, то иди в этом до конца.
Единственное, что меня беспокоило — это авторизация. В мире нет ничего более желанного для ИБ и ненавистного разработчиками, чем контроль доступа. И я знал, что довольно скоро мы доберёмся и до этого вопроса.
Если вам интересно распутать клубок асинхронного взаимодействия тысяч продюссеров и консьюмеров, узнать, где документация Kafka нас обманывает, а librdkafka и Confluent.Kafka не могут договориться, и как один потерянный пакет может привести к Permission denied, добро пожаловать под хабракат. Эта история для тех, кто догадался, что недостаточно было «просто включить флажок в конфиге».
Привет, Хабр! Меня зовут Виктор Корейша и я — руководитель направления Managed Services в Ozon. Я и моя команда, в том числе, отвечаем за всю инфраструктуру асинхронного взаимодействия между сервисами, которую строим на базе Kafka. А ещё я ведущий подкастов «Кода кода» и «Три тимлида заходят в бар».
Эта статья написана по мотивам моего доклада для DevOps Conf 2025. Расскажу нашу историю про внедрение авторизации и аутентификации в Kafka. Инженеры по эксплуатации найдут в ней обзор решений реализации SASL-сервера, разработчики — историю о конфликтах в production-ready клиентах, архитекторы — любопытные кейсы взаимодействия высоконагруженных систем, ну а менеджеры — эпос о внедрении технически сложных изменений в больших компаниях.
Давайте сразу договоримся: никаких ссылок и рекламы школ здесь не будет. Учился я сам, точечно докупал недорогие курсы по конкретным темам. Весь мой образовательный бюджет составил, наверное, тысяч 25.
В целом, этот текст — скорее самоанализ и небольшой отчёт, к которому я смогу вернуться со временем и понять, не изменились ли мои цели и приоритеты, и двигаюсь ли я всё ещё в нужном направлении.
На Хабре частенько говорят о дистрибутивах, так или иначе основанных на ядрах Linux или BSD. Но есть и совсем уникальные операционные системы, которые разрабатывались с нуля и полностью самодостаточны. Порой такие проекты создаются лишь одним человеком, яркий пример — TempleOS. Сегодня хочу рассказать о Visopsys, проекте визуальной операционной системы, которая уже 23 года разрабатывается Энди Маклафлином (Andy McLaughlin) в качестве хобби.
В последнее время я много работал с TPU и мне было интересно наблюдать такие сильные различия в их философии дизайна по сравнению с GPU.
Главная сильная сторона TPU — это их масштабируемость. Она достигается благодаря и аппаратной (энергоэффективности и модульности), и программной стороне (компилятору XLA).
Общая информация
Если вкратце, то TPU — это ASIC компании Google, делающий упор на два фактора: огромную производительность перемножения матриц + энергоэффективность.
Их история началась в Google в 2006 году, когда компания впервые начала размышлять о том, что же ей стоит реализовывать: GPU, FPGA или специализированные ASIC. В те времена было лишь несколько областей применения, в которых требовалось специализированное оборудование, поэтому было решено, что потребности компании можно удовлетворить при помощи незадействованных вычислительных ресурсов (compute) CPU её крупных датацентров. Но в 2013 году ситуация изменилась: функция голосового поиска Google начала использовать нейросети, и по расчётам для её реализации потребовалось бы гораздо больше compute.
Перенесёмся в настоящее: сегодня TPU лежат в основе большинства ИИ-сервисов Google. Разумеется, сюда включены обучение и инференс Gemini и Veo, а также развёртывание моделей рекомендаций (DLRM).
Давайте начнём разбирать внутренности TPU с самого нижнего уровня.
Друзья, вопрос не только в «зарплатных ожиданиях». Менять работу для технического, да и не только, специалиста – это стресс. Люди остаются на рабочем месте, даже когда рынок по зарплате вырастает в два раза! Но если один специалист уходит, то и другие легче решаются на перемены. Итак, как это происходит и к чему ведет.
...И тут HR делает самую главную ошибку – не поднимает заработную плату оставшимся сотрудникам. «Зачем? Работают и ладно.»
И вдруг «оставшиеся сотрудники» понимают, что делают работу за 150 т.р. при этом погружены в задачу и процессы компании, а новый, который «знает как надо», но при этом не понимает, почему это не пройдет, так как не сталкивался с реалиями – получает 250 т.р. да еще и должность ему обещали после испытательного, в которой, кстати, отказали предыдущему. Как итог – на hh появляется еще 3 резюме. Двух тут же переманивает к себе «первый ведущий», который уже освоился и пробил «свою команду», третий – уходи или в стартап, или в «интересную компанию», или в крупный холдинг «ДенегХотьЗавались». Стажер, которым никто не занимается, тоже сваливает, вписав себе навыки «мидла».
Пока Роскосмос кормит страну обещаниями о “возвращаемых” ракетах через пару лет, Honda уже посадила свою. Да, та самая Honda, которая делает мопеды и Civic. И это не единичный случай: Китай выводит на орбиту десятки аппаратов, SpaceX штампует запуски как часы, а в России — падение и десятки лет разработок в никуда.
Когда мы слышим слово «телеком», воображение обычно рисует антенны, мачты сотовой связи и характерные вышки с мигающими огоньками. Но за этим скрывается невидимая, куда более сложная система — опорная сеть. Это не про железо и радиосигналы, а про программное обеспечение, сеть микросервисов, миллионы сообщений в секунду — и людей, которые все это поддерживают и развивают.
КДПВ
Обычно сервер ассоциируется с чем-то дорогим и недоступным обычному человеку. Даже на вторичном рынке они пока еще стоят весьма существенно (если не рассматривать совсем уж допотопные экземпляры). Однако, есть и такие, которые можно приобрести весьма недорого.
Это так называемые блейд-серверы. Блейд-сервер (от англ. blade — лезвие) – концепция использования нескольких компактных серверов в одной общей корзине (шасси). Некоторые узлы сервера (такие как блоки питания, охлаждение, сетевые адаптеры, управление) вынесены за пределы сервера и сделаны общими для всех. Благодаря этому исключается излишнее дублирование и, соответственно, уменьшаются габариты и общее энергопотребление всей сборки. Увеличивается плотность вычислительной мощности на единицу объема серверной стойки. Из-за того, что единичный блейд-сервер бесполезен без корзины, а в корзине избыточен, они не пользуются спросом на вторичном рынке, а потому стоят весьма недорого.
Эта статья — крик души. О слепой погоне за IT-мечтой, о курсах, которые обещают сделать из вас гуру программирования за три месяца, и о деньгах, которые якобы посыпятся на вас, как из рога изобилия.
Но за красивой картинкой — тысячи часов проб и ошибок, выгорание, бессонные ночи и жёсткая конкуренция. Готовы ли вы на самом деле к этому пути? Или просто верите в сказку?
Warning! Warning! Warning! В этой статье я буду душнить…
— Я не продаю часы, — ответил я.
— Ну хорошо, тогда что насчёт дней, недель, месяцев? Мне нужно хоть что-то, чтобы прикинуть потенциальные расходы.
— Я обычно оцениваю работу под ключ. Часовой ставки у меня нет.
— У всех есть такая ставка, хотят они того или нет.
— Что ж, здесь я вынужден согласиться. Но всё же хотелось бы для начала внимательно взглянуть на проект, от него многое будет зависеть, — попробовал я соскочить с темы.
Потенциальный клиент не стал дальше на меня давить. А уже потом я, засыпая поздним вечером и переваривая события дня, хлопал себя по лбу со словами: «Надо было просто ответить, что он застал меня подобным вопросом врасплох и что я готов ответить на него чуть позже!».
Почему же я сразу не назвал своей часовой ставки?
Я сижу под Linux, но иногда нужна винда. До недавнего времени у меня был обычный dual boot, но сейчас я реализовал свой идеальный сетап:
- основная система - Linux
- Windows - на выделенной SSD
- на нее можно загрузиться как из груба, так и из виртуалки
- с пробросом второго GPU (дисплей на отдельный физический выход)
- с качественным удаленным подключением (как RDP, но быстрое) - можно играть в игры
Ниже опишу что и как сделал.
Практически все заводские Zigbee датчики протечки не умеют посылать команды напрямую исполнительному устройству, например мотору крана. И если сеть рухнула, например отключили электричество, то система антипротечки не сработает, даже если она построена на батарейных устройствах. Прямой биндинг решает эту проблему.
Привет! Как и многие в 2025 году, я постоянно работаю с ChatGPT и Gemini: они помогают мне в работе, отвечают на сотни вопросов и просто развлекают. За время работы с ИИ у меня накопилась целая коллекция мини-промптов, которые делают процесс проще, результативнее и даже веселее. Сегодня делюсь с вами.
Я закончил московский политех (ранее МГТУ “МАМИ”) по специальности "конструктор-технолог литейного производства" с красным дипломом. В 2010 году пошел работать в Роскосмос.
Недавно меня заинтересовала такая задача: как лучше всего определить, что в строке есть гласная?
Казалось бы, тривиальный вопрос, правда?
Но, начав разбираться, я осознал, что задача гораздо глубже. Я бросил себе вызов: придумать как можно больше способов обнаружения гласной. Я даже попросил присоединиться ко мне нескольких друзей. Какой способ самый быстрый? Каким никогда не стоит пользоваться? Какой самый умный? Какой самый удобочитаемый?
В этом посте я рассмотрю 11 способов обнаружения гласных, алгоритмический анализ, дизассемблирование байт-кода Python, реализацию CPython и даже исследую опкоды скомпилированного регулярного выражения. Поехали!
