Бэкенд

CSI-драйвер и Swordfish API: как заставить Kubernetes дружить с любым хранилищем

В современных enterprise-средах важно обеспечить стандартизированный доступ к системам хранения данных (СХД) от разных производителей, избегая жесткой привязки к конкретному вендору. Одним из решений этой задачи является использование CSI-драйвера, который взаимодействует с Swordfish API. Такая интеграция позволяет Kubernetes автоматически создавать, подключать и удалять тома, избавляя команды от множества ручных операций.

Процесс выглядит так: когда приложение в Kubernetes запрашивает постоянное хранилище, оркестратор формирует PersistentVolumeClaim (PVC) с нужными параметрами — размером, типом и характеристиками. Kubernetes определяет, что создание тома должно выполняться через CSI-драйвер, и передает запрос в эмулятор Swordfish API. Тот создает том, а в случае работы с файловыми системами (например, NFS) дополнительно настраивает подключение к серверу и возвращает CSI-драйверу сведения о готовом ресурсе.

Дальше Kubernetes связывает созданный том с заявкой PVC, после чего CSI-драйвер монтирует его на рабочий узел к нужному контейнеру или поду. Эмулятор Swordfish API при этом добавляет путь к каталогу в конфигурацию NFS (/etc/exports), что позволяет клиентам подключаться к сетевому хранилищу.

Когда хранилище больше не нужно:

• DevOps удаляет PVC.

• Kubernetes вызывает NodeUnpublishVolume для размонтирования тома с узла.

• CSI-драйвер передает команду Swordfish API.

• API удаляет том и освобождает ресурсы (в случае NFS — удаляет запись из /etc/exports и каталог).

• Kubernetes удаляет объект PV, завершая процесс.

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

Если интересно, как самостоятельно разработать CSI-драйвер с поддержкой Swordfish API и запустить его даже без реального оборудования, то об этом — в статье, где пошагово показано, как реализовать и протестировать решение.

В прошлом году я помог Дмитрию Свиридкину подготовить и опубликовать цикл из 12 статей "Путеводитель C++ программиста по неопределённому поведению". Теперь этот расширенный, доработанный и обобщённый материал доступен в виде печатной книги:

Экскурс в неопределенное поведение C++ / Д. О. Свиридкин, А. Н. Карпов, – СПб.: БХВ-Петербург, 2025. – 384 с. – (Профессиональное программирование)

ISBN 978-5-9775-2073-7

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

Книгу можно найти в offline и online магазинах.

Ещё какое-то количество книг я и коллеги раздадим в качестве сувениров и призов на различных мероприятиях, таких как:

• Сплошные плюсы. Клуб С++ разработчиков.

• Митап «Мир С++».

• И т.д. Узнать о подобных мероприятиях можно, например, в моём ТГ канале "Бестиарий программирования".

Приятного и вдумчивого чтения!

Рецепт приготовления кролика от нашего Backend Lead U^ｪ^U

Брокеры сообщений, в частности RabbitMQ, широко применяются во всем IT. Однако это далеко не магическая коробка, а написать код так, чтобы не потерять свои сообщения — крайне нетривиальная задача.

Этим летом наш Backend Lead Витя Михайлов выступил на Saint HighLoad++ 2025, где рассказал, как же правильно готовить RabbitMQ, и поделился классными кейсами.  

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

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

Я не про банальные приёмы вроде зайти к начальнику в чистой рубашке и после обеда, когда он сыт и добр. Я про тёмную сторону - оккультные технологии! Вот если человек подписан на канал об астрологии, то он точно попросит повышение, когда Марс в десятом доме. А если нет, то его партнёр пошлёт сигналы во Вселенную.

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

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

P.S. Интересно, а пользуется ли нанимающая сторона какими-то секретными техниками поиска и найма?

Выходные не прошли зря.

В пьяном дурмане (это наркоз от попоболи) я продолжал разработку своего AI-трейдера, воспользовался вашими предложениями в телеграм (огромное спасибо за подсказку), и кое-что получилось:

• Добавлены бусты LightGBM (LGBMRegressor) и CatBoost (CatBoostRegressor). Теперь обучаю три модельки, сравниваю результаты и выбираю лучшую.

• Переписал по 500 раз все методы, включая обучение моделей, торговую стратегию и тесты.

И вот результат тестовой торговли модельки на исторических данных:

Начальный баланс: 1000 USDT

===== Отчёт по сделкам =====

Всего сделок: 66

Винрейт: 40.91%

Средний PnL: 44.82 USDT

Максимальная просадка: -35.63%

Финальный баланс: 3958.17 USDT

В общем, готов богатеть. И пусть только попробует не показать такой результат на реальном бабле!)))

Окей, собственно говоря, в подтверждение моих слов о том, что ИИ - это просто перехайпанная стагнация, в которую гигатоннами сливают деньги от нефиг делать - встречайте: ChatGPT 5!

Он вообще не отличается от предыдущего ChatGPT. Программисты довертели всяких финтифлюшек, как-то: теперь, когда юзер начинает злиться на машину, машина меняет модель на более продвинутую, чтобы не просто выдать тупой ответ, но сделать это с пафосом и показать, что об ответе было «подумано».

То, что я заметил, так это то, что теперь, если модель не может ответить в одном сообщении, то вместо того чтобы разбивать сообщение на части и продолжать генерировать, модель просто регрессирует и перестаёт вообще что-то делать. Особенно хорошо это видно, когда модели скармливают текст эдак на 5000 слов с инструкциями о необходимости проверки орфографии (отдельно убеждаясь, что модель обязана не менять стиль или содержание). Ответ идёт отлично в самом начале, но к концу сообщения машина начинает собирать абзацы в предложения, укорачивая и укорачивая текст.

Итог? У нас на руках одна модель, которая одна за всех. Почему? Потому что 99,95 % всех юзеров не знают разницы между 4.1 и 4о. В таком случае OpenAI сможет урезать финансирование и охладить своё безудержное использование серверов.

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

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

Что это? Оптимизация расходов.

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

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

Где учиться бэкенду

Привет! Мы на Хабр Карьере собираем сотни онлайн-курсов в IT или digital на маркетплейсе курсов и каждую неделю делаем подборки обучений для тех, кто хочет учиться какой-то специализации с нуля или для тех, кто уже в профессии, но чувствует, что хочет прокачать навыки.

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

— Алгоритмы и структуры данных

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

— Git

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

— Python 

Язык общего назначения, популярен в вебе, автоматизации, ML.

— FastAPI

Лёгкий и быстрый фреймворк для создания REST API с поддержкой async/await и автогенерацией схем.

— Django

Фреймворк для быстрой разработки web-приложений, включает ORM, авторизацию и админку из коробки.

— JavaScript / TypeScript

JavaScript — язык для веб-интерфейсов и серверной логики (через Node.js). TypeScript — его надстройка с типизацией, упрощающая масштабируемую разработку.

— Java / Spring

Java — строго типизированный язык. Spring — основной фреймворк для создания REST API, микросервисов и корпоративных приложений.

— Go

Компилируемый язык от Google с простым синтаксисом и встроенной поддержкой параллелизма. Используется в highload-системах, DevOps и backend-разработке.

— C#

Язык от Microsoft, используется с платформой .NET. Применяется в разработке desktop-, web-, enterprise- и игровых приложений.

— PHP

Скриптовый язык, ориентированный на веб. Часто используется с CMS (например, WordPress) и фреймворками (Laravel, Symfony).

— Ruby

Язык с лаконичным синтаксисом. Наиболее известен благодаря фреймворку Ruby on Rails, ориентированному на быструю разработку веб-приложений.

— SQL / PostgreSQL

SQL — язык запросов к реляционным БД. PostgreSQL — популярная СУБД, используется в веб-приложениях, аналитике, поддерживает расширения и транзакции.

— Docker

Инструмент для упаковки приложений в контейнеры. Обеспечивает воспроизводимую среду разработки и удобное развертывание.

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

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

→ Смотреть курсы по всем специализациям

50 000 пользователей зарегистрировались в Amvera Cloud

Друзья, 8 августа 2025 в облаке Amvera зарегистрировался 50 000-й пользователь.

У нас юбилей!

В юбилей принято дарить подарки, и такой ждёт нашего юбилейного пользователя с ником aryachay. 

Amvera Cloud – облако для простого запуска проектов со встроенным CI/CD (деплой идёт через Git или загрузку файлов в интерфейсе). C Amvera вам не нужно думать о настройке NGINX, виртуальных машин и другой инфраструктуры.

Как понять, что ИИ не даст хорошего результата?

Бывало такое: пока игрался с промптами, мог уже два раза написать код сам, но нормального результата так и не добился?

Наш бэкенд-лид Максим вывел правило трех попыток

Как понять, что хороший результат точно не получится? Я обычно пробую два-три раза. Не больше трех точно, потому что фактически, если на третий раз получаю плохой ответ, скорее всего, уже ничего лучше не придумаешь – дальше сам. 

Тратишь время на ожидание результата, потом проверяешь этот результат: в первый раз ушло 15 минут, не получилось. Пробуешь другой запрос, это еще 15 минут, тоже не получилось. Третий раз еще 15 минут. И если руками задача делается за 2-3 часа, то нет смысла убиваать время на попытки сэкономить 5 минут. Да и лимит стоит денег, тратить впустую его не хочется. Поэтому такие условные ограничения в голове: два-три раза и дальше сам.

Кстати, Максим написал статью о том, как они в команде 2,5 месяца пилотили Junie. Успехи, цифры и боли - все здесь.

Если нужна бесплатная альтернатива Cursor AI и Copilot в VS Code, вот самое быстрое и оптимальное решение, как мне кажется:

1. Качаешь VS Code

2. Устанавливаешь расширение Continue - open-source AI code assistant

3. Получаешь бесплатный API key от думающей модельки Deepseek: https://openrouter.ai/deepseek/deepseek-r1-0528:free/api

4. Устанавливаешь соответствующие настройки провайдера и модельки в Continue. Можно это сделать в yml файле, выглядеть он будет так:

name: Local Assistant
version: 1.0.0
schema: v1
models:
  - name: deepseek-r1
    provider: openrouter
    model: deepseek/deepseek-r1-0528:free
    apiBase: https://openrouter.ai/api/v1
    apiKey: 
    

5. Пользуешься чатиком или агентом со всей дури.

Можно поиграться с настройками, провайдерами и модельками, но это уже сами.

Когда тебя спрашивают про Питон, а ты только “Летающий цирк“ смотрел.

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

Сказал что понимает, что я пишу на 1С, но может ли он ко мне обращаться с вопросами. Хороший повод посмотреть что это за язык. Нужно какое-то ТЗ.

Пусть в SQL есть таблица «Prices» с двумя колонками. «Product», «Price». Требуется посчитать и вывести среднюю стоимость.

Средняя стоимость = Сумма/количество различных позиций.

Задача стоит. На чём её решать?

Есть компьютер с Windows 11.

В качестве движка БД думаю поставить SQLite. Так же нужно установить Python.

IDE наверное будет перебором, поэтому поставлю Sublime Text с каким-нибудь плагином. Так-с. Что я знаю о Python. Он полный по Тьюрингу. Блоки определяются отступами. Есть объекты…. Вроде всё.

Приступим. Что нам понадобится:

1. Установленная SQLite.

2. Созданная БД с нужными данными.

3. Объект «Подключение» в Python.

Так-с SQLite. На https://www.sqlite.org/download.html есть собранный для Windows. В принципе логично, но всё равно приятно… Ага, вот и первый нюанс. Есть DLL и есть tools.

Похоже придётся чутка почитать... Пишут ставить Tools “sqlite-tools-win-x64” (Если кто-не слушал, то настойчиво рекомендую послушать Tool – Vicarious).

Скачиваем — распаковываем, видим 4 exe файла.

Нам нужно:

1. Создать БД.

2. Создать таблицу.

3. Заполнить таблицу.

4. Написать запрос для получения данных таблицы.

4. Написать запрос для получения среднего.

Открываем документацию к SQLite. Приступим.

1. Создаём БД: C:\sqlite> .\sqlite3.exe average.sqlite;

2. Создаём таблицу с колонками нужных типов: create table prices(product text, price int);

3. Проверяем что таблица создалась: sqlite> .tables;

4. Заполняем строки:

insert into prices values('Bike',1);
insert into prices values('Car',2);
insert into prices values('Boat',3);

5. Проверяем заполнение: select * from prices;

6. Пишем запрос средней цены: SELECT AVG(price) AS average_price FROM prices;

Получили 2.

Отлично! С этим разобрались.

Теперь нужно:

1. Установить python.

2. Разобраться объект какого класса следует использовать для подключения к SQLite.

3. Получить результат запроса.

4. Вывести результат запроса.

Смотрим.

1. Скачиваем learn_python.winget.

2. winget configure -f C:\Users\Имя пользователя\Downloads\learn_python.winget.

3. Пишем код в текстовом редакторе:

#https://docs.python.org/3/library/sqlite3.html

import sqlite3

conn = sqlite3.connect('C:\\sqlite\\average.sqlite')

cursor = conn.cursor()

cursor.execute('SELECT AVG(price) AS average_price FROM prices;')

result = cursor.fetchone()

if result and result[0] is not None:

print(f"Average Price is {result[0]:.2f}")

else:

print("No prices found.")

conn.close()

4. Сохраняем как print_average_price.py.

5. Запускаем: python3.13.exe .\print_average_price.py.

«Average Price is 2.00».

Отлично! Задача выполнена.

Говорим на языке событий: что даёт ивент-шторминг и как его правильно провести

Привет! Я Иван Чернов, системный архитектор, в этом посте расскажу про ивент-шторминг.

В Островке есть набор сервисов, который разбит на логические блоки так, чтобы в рамках блока можно было итерировать: Островок, Островок B2B и Островок Командировки. При этом запускать новые фичи, которые будут сквозь эти слои прорезаться. 

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

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

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

На этих циклах фокусируемся на доске в Miro во время встречи. 

В ивент-шторминге 3 этапа: 

1. Сейлзы выстраивают по циклам цепочку событий: от «клиента у нас ещё нет» до «клиент нас окончательно покинул». Даже в простых цепочках 20–30 действий. В готовом таймлайне есть happy pass: клиент успешно прошёл весь путь. И альтернативные пути: что-то пошло не так.

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

3. Выявляем, какие агрегаты работают с событием. Мапим команды: клиент регистрируется, в работе участвует команда регистрации. 

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

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

Поделюсь советами, как круто провести ивент-шторминг.

Онлайн-формат

● Для проведения онлайн достаточно доски в Miro.

● Разбивайте встречу на три части, каждая встреча — один этап.

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

● Максимум людей для успешной фасилитации онлайн — 8–10 человек.

Подбор людей и подготовка

● Соотношение участников: 70% бизнеса, 30% разработки.

● Ищите представителей бизнеса в оргчате выбранного домена: спрашивайте у руководства, «кто тут самый инициативный».

● Вам нужны работники «с полей», которые лучше всего шарят в процессах, и тимлиды первого уровня.

● Берите людей из разных направлений домена. 

● Бизнес-участники должны понимать: ивент-шторминг — процесс обучения, они эксперты, а разработка — ученики. Им нужно говорить на своём языке, а не подстраиваться под разработку.

● Дайте участникам базовый словарь. Четыре самых важных слова: актор, команда, событие, термин.

● Важны вводные по времени и цели: на сессию уйдёт суммарно 6–8 часов, она даст единое понимание процессов.

Фасилитация

● На старте не бойтесь повторить все вводные.

● Дайте сейлзсам 10 минут на то, чтобы каждый выстроил индивидуальный таймлайн, дальше начинайте мёржить таймлайны с общим обсуждением.

● Событие — факт в прошедшем времени, его не отмотать. Следите, чтобы так и записывали. 

● Первым делом простройте happy pass, иначе у вас не выстроится цельное видение процесса. Альтернативные ветки обозначьте на первом этапе, а достраивайте на втором, проверяя таймлайн с конца.

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

● Организуйте пост-процессинг: важно передать разработке результаты, объяснить, какие процессы у нас уже верно реализованы, а где нужно обновление и дополнительное внедрение.

Что такое архитектура ПО и почему она не про красивые диаграммы

🏗️ Архитектура программного обеспечения — это не просто модное слово для повышения ставки на собеседовании. Это фундамент, на котором строится вся система.

Что это такое на самом деле?
Архитектура ПО — это структура компонентов системы, их взаимосвязи, взаимодействия с внешней средой и принципы разработки. Звучит скучно? А вот и нет! Это как план города: без него у вас получится не Москва, а какая-то деревня Гадюкино с кривыми улочками.

Зачем это нужно?

• Снижает сложность системы через декомпозицию

• Определяет рамки развития (чтобы не росло как раковая опухоль)

• Помогает команде говорить на одном языке

• Экономит нервы и деньги в долгосрочной перспективе

Под капотом архитектура отвечает за:
✅ Разбиение системы на модули (как LEGO, только для взрослых)
✅ Способы взаимодействия компонентов (REST, RPC, события)
✅ Распределение ответственности между модулями
✅ Выбор технологического стека

Простой пример:
Представьте интернет-магазин. Без архитектуры у вас будет один гигантский файл на 50,000 строк, где корзина покупок живёт рядом с логикой оплаты, а пользовательские данные перемешаны с каталогом товаров. С архитектурой — отдельные модули: UserService, CatalogService, PaymentService, каждый со своей зоной ответственности.

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

Компонент — часть системы, выполняющая изолированную функцию. Думайте о нём как о сотруднике в компании: у каждого своя роль, свои обязанности, и если он заболел — его можно заменить.

Пример компонентов:

• Authentication Service (следит, чтобы чужие не лезли)

• Notification Service (шлёт уведомления)

• Data Storage (хранит данные, очевидно)

Интерфейс — способ взаимодействия между компонентами. Это как протокол дипломатии: все знают правила игры, никто не лезет с кулаками.

Типы интерфейсов:

• REST API (классика жанра)

• Message Queue (асинхронные сообщения)

• RPC (удалённые вызовы)

• Database API (работа с данными)

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

Примеры связей:

• HTTP-соединения (веб-траффик)

• TCP/UDP сокеты (низкоуровневая связь)

• Message Brokers (Apache Kafka, RabbitMQ)

• Database connections (пул соединений с БД)

Модуль — логическая группировка компонентов по функциональности. Это как департаменты в компании: HR, IT, Бухгалтерия.

Примеры модулей:

• User Management Module (всё что касается пользователей)

• Payment Processing Module (платежи и транзакции)

• Analytics Module (метрики и отчёты)

Сервис — автономная единица бизнес-логики с чётко определённой ответственностью. Это как мини-приложение внутри большого приложения.

Примеры сервисов:

• Order Service (управление заказами)

• Inventory Service (управление товарами)

• Billing Service (выставление счетов)

Хранилище данных — компонент, отвечающий за персистентность информации. Это как склад или архив компании.

Типы хранилищ:

• Реляционные БД (PostgreSQL, MySQL)

• NoSQL (MongoDB, Redis)

• Файловые системы (S3, локальные диски)

• Кэши (Redis, Memcached)

SLA — характеристики работы сервиса. Это контракт: "обещаю работать 99.9% времени и отвечать за 200ms".

Зачем нужны SLA:

• Понимание ожиданий от системы

• Планирование мощностей

• Определение критичности сервисов

• Основа для мониторинга

Практический пример:
Сервис авторизации должен:

• Отвечать за 100ms в 95% случаев

• Быть доступным 99.95% времени

• Выдерживать 1000 RPS

Чеклист для правильного проектирования:
✅ Каждый компонент имеет чёткую ответственность
✅ Интерфейсы документированы
✅ Связи (способы взаимодействия) определены
✅ Деление на сервисы произведено
✅ Способ хранения данных определен
✅ SLA определены и измеряемы
✅ Зависимости между компонентами минимальны

Помните: хорошая архитектура начинается с понимания базовых элементов. Без этого ваша система превратится в спагетти-код корпоративного масштаба.

Как устроена стажировка на backend в Альфа-Банке — вся правда изнутри

• Хочешь знать, дают ли стажёрам настоящие боевые задачи, или ты просто будешь «перекладывать JSON-ы»?

• Интересно, реально ли совместить учёбу и удалённую работу и почему документация — это не халява, а адреналиновый квест?

• Не хочешь в очередной раз читать банальности о «стажёрском выживании», а узнать всё по-честному: от первой ошибки на собесе до рефакторинга в большом проде?

Меня зовут Кирилл, я студент 3-го курса НИУ МЭИ, направление — «Информатика и вычислительная техника», а также Junior Python Backend-разработчик в Альфа-Банке. Написал статью «Самое главное о том, как проходила моя стажировка на backend-разработчика» для студентов и ребят без опыта работы. Читайте, чтобы узнать, как в Альфе растят специалистов — и что делать, чтобы вам тоже предложили войти в команду после стажировки!

Что ты сделал для хип-хопа IT-инфраструктуры в свои годы? Писал UEFI и BMC для высоконагруженного оборудования 

В YADRO есть распределенная команда, которая разрабатывает и сопровождает собственные программные реализации UEFI (BIOS) и BMC. Для самого разного оборудования — от серверов до телеком- и клиентского оборудования. 

Познакомиться с командой → 

Какие задачи выполняют в команде BIOS/BMC: 

• Реализуют программную поддержку новых аппаратных продуктов компании, определяют протоколы и методы взаимодействия между программными и аппаратными компонентами продуктов YADRO.

• Проводят верификацию микрокода и выполняют проверку прошивок микросхем всех продуктов компании. Выстраивают стратегию тестирования.

• Исследуют новые программные и аппаратные технологии для применения в продуктах. Рефакторят код для повышения производительности.

• Придумывают методы безопасного обновления прошивок BIOS и BMC, чтобы обеспечить минимальный или нулевой даунтайм.

• Добавляют новые фичи и меняют существующие — от WebUI до политик управления аппаратными компонентами.

Команде нужно больше инженеров — разработчиков на С/C++, тестировщиков, автоматизаторов и техлидов. Знакомься с вакансиями на сайте и вовлекайся в трушные инженерные задачи на современном технологическом стеке. 

Под пост в телеграм про наш ответ аналог Grafana пришли руководители "Лаборатории Числитель" и конкретно "Пульта", в чью систему входит платформа мониторинга и анализа "Графиня".

Дмитрий Унтила и Владимир Утратенко любезно ответили на ряд вопросов по платформе, и я хотел бы подвести краткое резюме:

• Запрос на аналог Grafana появился в момент продажи "Пульта", так как "не всем можно брать забугорный опесорс себе в контур. Потому решили делать. А название Графиня просто ради лулзов."

• Графиня писалась с полного нуля. Хотя предложение взять за основу Grafana было, но команда смогла обосновать геморрой, который на неё упадёт, если взяться за доработку, и объяснила руководству, почему лучше сделать с нуля.

• Время разработки: 3 месяца - MVP, 6 месяцев - 1 релиз.

• Технологический стек: фронтенд: TypeScript + React 18, бэкенд: TypeScript + Node.js, база данных: MongoDB, плагины: Java.

• На мое предложение сделать проект опенсорс Дмитрий Унтила пообещал подумать. Но, понятное дело, если это часть коммерческого продукта, прям сильно думать в лаборатории не будут))

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

Благодарю парней за такой актив и обратную связь, рад, что у людей есть на это время!

Ко мне в телеграм канал заглянул один из разработчиков Графини (убийцы Grafana), с пояснением, зачем они её родили, и что писали полностью с нуля.

Я верю.

Многие крупные компании применяют Go, а спрос на опытных инженеров, владеющих Go, высок как никогда. Онбординг проходит действительно быстро, и у нас есть успешные тому примеры. Все благодаря общей простоте языка и отсутствию function coloring. В карточках рассказываем, как это получилось у Кирилла в 2ГИС↓

Не говнокод, а плодородная почва для прекрасного кода будущего.

Знакомо ли вам это чувство, когда вы приходите в проект — и вам кажется, что вокруг один говнокод? Нет, не кажется. Я называю это "нарастающим циклом улучшения кода". Каждый новый разработчик уверен: до него было плохо, а теперь всё станет хорошо. И каждый следующий — тоже. Забавно, но никто не догадывается, что предыдущий думал ровно то же самое.

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

Так что всё хорошо: код проекта действительно улучшается. А твой код — плодородная почва для прекрасного будущего.

Успейте присоединиться к реферальной программе Ozon Tech и заработать 150 000 ₽ за рекомендацию друга.

31 июля завершаем приём резюме. Если вы не работаете в Ozon, а ваш друг за последние 3 месяца не проходил к нам интервью, участвуйте!

Какие вакансии участвуют в программе: 

• старший Data Scientist;

• старший C#-разработчик.  

Как отправить резюме:

1. Подберите релевантную опыту вакансию на лендинге. 

2. Заполните короткую форму и приложите к ней резюме. 

3. Дождитесь ответа HR-специалиста — обычно рассмотрение занимает до 5 рабочий дней. 

Что будет дальше

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

Ждём ваших рекомендаций!