Technotext

Всем привет! Меня зовут Саша, я руковожу группой разработки Composer Core в Ozon Tech. В этой статье я расскажу о том, как устроена пользовательская часть одного из ведущих российских маркетплейсов, в развитии которой на момент написания статьи участвуют сотни специалистов из десятков команд. При наличии такого количества людей разрабатывать новую функциональность, не рискуя сломать уже существующую, является достаточно сложной задачей.

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

Продукт, который мы разработали, вряд ли когда-нибудь станет open-source-проектом, так как он слишком зависит от специфики инфраструктуры Ozon Tech. Но основные принципы могут быть полезны при проектировании похожих систем.

Привет, Хабр! Меня зовут Виктория Юльская, и я старший системный аналитик в Ozon.

Я думаю, здесь найдётся много людей, которые хоть раз работали с документацией API в Confluence. Да-да, те самые километровые страницы на каждый метод — с описанием всего и вся в виде текста, таблиц, диаграмм последовательности и т. д.

Зачастую такая документация API в Confluence устаревает ровно в тот момент, как её закончили писать. После передачи задачи в разработку, как только что-то непонятно, куда все идут? Правильно, к аналитику — «А как это работает? А что это значит? А что если...?».

Ну вот же дока, там все написано... но обычно никто не хочет читать огромную доку на метод, быстрее же спросить. И зачастую у самих аналитиков есть вопросики по актуальности этой документации (уже есть новые договорённости со встреч, комментарии в документации и т. д.).

Есть ли более эффективный способ ведения и поддержания документации API в актуальном состоянии? Давайте разбираться.

Сумрачная картинка: большое помещение, мало света. Стол и рядом стул, на котором сидит человек. Он работает за ноутбуком. Чувствую его усталость: он сегодня уже долго работает. Его что-то отвлекает: письмо. Электронное письмо. Он нажимает на ссылку, но ничего не появляется на экране. Всё в порядке. Но на сетевом уровне уже поселилось зло: ЧЕРВЬ!!! Спустя неделю червь выкачает данные, из-за чего компания потеряет десятки-сотни миллионов рублей.

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

Эта статья будет полезна и крута всем: узнаете, как помочь своим коллегам узнать больше об информационной безопасности в незанудной форме! На одном из мест работы я смог за пару лет повысить общий уровень знаний сотрудников в 5 раз! Меня зовут Маг Владони Миша, и теперь я занимаюсь Security Awareness в Ozon. Инциденты информационной безопасности, возникающие из-за человеческой ошибки, — самые распространённые (по данным РТ). Для минимизации количества таких инцидентов необходимо повышать осведомлённость в вопросах ИБ, т.е. заниматься Security Awareness.

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

Меня зовут Егор Прокопьев, и я фронтенд-разработчик в Ozon.

Третья версия полюбившегося многими фреймворка Vue вышла уже давно, и большинство использующих его произвели обновление до новой версии. Но всегда будут такие, как наша команда, кто откладывал этот переход в дальний ящик техдолга — ведь есть более приоритетные задачи! Однако рано или поздно этот день настаёт, и вот и для нас он пришёл.

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

Привет! Меня зовут Кермен, я — аналитик на второй линии SOC. Наша команда исследует данные от инфраструктуры и сервисов Ozon для выявления нелегитимной активности: от нарушения политик информационной безопасности до целенаправленных атак.

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

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

Нам захотелось навести порядок, поэтому позаимствовали опыт разработчиков: сделали новый формат хранения, добавили больше метаинформации, настроили CI/CD, и теперь у наших объектов есть свой жизненный цикл, включающий в себя этапы разработки, тестирования, перенос в продакшн, пересмотр и отключение.

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

Интересное начало, не так ли? Меня зовут Роман, и я младший инженер информационной безопасности Ozon. В этой статье я расскажу о проблеме отсутствия авторизации доступа к Docker daemon / Docker Engine API / командам Docker при работе с контейнерами в экосистеме Docker и как это можно решить при помощи 11 почти стихотворных строчек bash.

Говоря о стихотворчестве, первое, что приходит мне в голову, это уроки литературы, где моим самым любимым романом был «Евгений Онегин». В школе учитель литературы говорила нам: «Это вы сейчас это не понимаете... Уже потом, спустя год, пять или даже 20 лет, вы вновь прикоснётесь к книгам, которые, казалось бы, вы уже знаете вдоль и поперёк. И вот тогда вы поймёте всё то, что мы с вами тут обсуждаем, или даже откроете для себя что-то, о чем и не догадываетесь».

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

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

Статья про то, как помигать светодиодом при помощи Arduino была весьма благосклонно воспринята аудиторией Хабра. В конце той статьи был опрос с большим списком тем для следующей публикации. С заметным отрывом победил вариант «Анбоксинг бухты кабеля ВВГнг». Что ж, желание читателей — закон для автора.

Давайте натрём наши болиды до блеска и посмотрим, как они входят в повороты компиляторных оптимизаций на примере использования std::array. Смогут ли они не только не уступить, но и обогнать встроенный массив?

Мало какая компания пользуется среди поклонников компьютера ZX Spectrum такой любовью и уважением, как Ultimate Play the Game. За свою недолгую историю она выпустила два с лишним десятка игр, бóльшая часть которых моментально становились бестселлерами. Многие из них мы ставим на «Спектрумы» в Яндекс Музеях. Особенной любовью публики пользуются Jetpac и Knight Lore, причём последняя зачастую заставляет посетителей удивлённо переспрашивать: «А этой игре точно недавно стукнуло 40 лет?»

В шедевры Ultimate Play the Game я начал играть с того момента, как у меня появился ZX Spectrum — то есть с 1991 года. Тогда мало кто знал, откуда появилась эта компания и как она умудрилась наделать такое количество прекрасных игр за столь короткое время.

И вот, спустя много‑много лет, я решил найти ответы на эти вопросы. Для этого я достал с полки все фирменные игры Ultimate, купленные в Великобритании, для удобства скачал их образы из интернета и потратил несколько дней, чтобы как следует в них наиграться. А затем обложился журналами Crash, Your Sinclair и Sinclair User, нашёл в интернете несколько десятков статей про Ultimate Play the Game и её создателей… И погрузился в расследование.

Кто же эти гении, буквально за полтора года прошедшие путь от Jetpac до Knight Lore? И почему информации о создании всех игр Ultimate так мало? Давайте разбираться вместе.

Привет, Хабр!) Меня зовут Ильяс. В этой статье мы разберём известную идею — keepalive в межсервисном взаимодействии, которая спасла уже не одну компанию в трудное время :). Но чтобы добавить интереса, мы разберём, какие проблемы в keepalive принесли современные технологии (ведь что может пойти не так с этой простой идеей?). Поэтому в статье мы рассмотрим механизмы, которые позволяют проверять стабильность соединения между клиентом и сервером в случае, когда обычные TCP keepalive из-за сложности архитектуры не могут определить состояние сервера.

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

Привет! Меня зовут Настя, я старший системный аналитик в X5 Tech. Я рисую sequence-диаграммы каждый день на протяжении четырёх лет. За это время я прошла все круги ада по Данте, то есть попробовала разные инструменты для рисования этих самых диаграмм. Пока не встретила его – PlantUML. 

Что удивительно, инструмент довольно не новый, но тем не менее лучше него я пока не встречала. А ещё удивительно, что он не особо популярный. Когда мы запустили в управлении системного анализа первый воркшоп по PlantUML, за 3 минуты после анонса пришли 12 заявок от аналитиков разных грейдов – от Junior до Lead. 

В процессе подготовки материалов к воркшопу мы искали статьи и литературу, которые помогли бы дополнительно изучить sequence-диаграммы в PlantUML. Ничего интересного мы не нашли. 

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

Поэтому и появилась эта статья. 

Всем привет, меня зовут Илья Аллендорф, я занимаюсь дизайном внутреннего продукта в X5 Tech. В статье расскажу, как я улучшил подготовку макетов для разработки и навёл порядок в рабочем проекте в Figma.

В 2023 году я пришёл в новый продукт, который разрабатывался с нуля. За два года мы запустили MVP, перевели бизнес-процесс в продукт, достигли целевых метрик, а ещё совершили ошибки и сделали ценные выводы. Кроме того, мы ускорили сycle time, улучшив взаимодействие с дизайном: навели порядок в Figma, договорились с аналитиками, упростили жизнь разработке и уменьшили этап дизайн-ревью.

Сегодня поговорим о неочевидной особенности некоторых коллекций в .NET. Долго вокруг да около ходить не будем и начнём с задачки на самопроверку.

Привет, Хабр! Меня зовут Дмитрий Селютин, я ведущий разработчик команды R&D в Cloud.ru.

Ситуации, когда при решении совершенно конкретной задачи упираешься в сложности откуда-то сбоку, возникают в разработке с завидной регулярностью. В задачах, зависящих от автоматизации, очень часто случается, что слабым местом оказываются непосредственно инструменты для этой автоматизации, если они вообще есть. Такие инструменты могут рождаться и умирать, но порой они могут возрождаться заново. Сегодня поделюсь рассказом о том, как в ходе исследований производительности нашего облака Cloud.ru Evolution мы внезапно сделали SDK и CLI посредством генерации кода и интроспекции. Статья будет полезной всем, перед кем стоит задача быстро обернуть сгенерированный API на Python в нечто более симпатичное и поможет из этого автоматически сделать CLI. Ну а для тех, кто не связан с темой, это будет поучительная история из разряда «если у вас завалялся кусочек кода, не спешите его выбрасывать».

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

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

TLDR. Я примерно год создавал курс из 141 урока. Курс получился хороший, все кто проходят рады и пишут положительные отзывы. Я пытался его продавать, в лучшем случае у меня получалось отбивать рекламу в ноль. Короче, я хороший разработчик, я хорошо доношу материал, но я плохой маркетолог. Все эти таргреты, ретаргеты, воронки, шморонки — тоска унылая. Мне гораздо веселее и понятнее заработать на создании и запуске IT-продуктов, чему я и учу в этом учебнике. Так что пишу эту статью, чтобы сообщить вам о существовании моего курса и предложить всем желающим абсолютно бесплатно получить от него пользу 🙂

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

Привет, Хабр! Меня зовут Станислав Егоркин, я инженер юнита IaaS департамента разработки Infrastructure в Авито. В этой статье я расскажу про инструмент, который мы используем для обнаружения деградаций на нодах в кластерах Kubernetes, а также покажу дашборд, где мы наблюдаем за состоянием всех наших нод.

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

Когда только начинаешь карьеру разработчика, часто гложет сомнение: верно ли я выбрал язык программирования? Может, он уже устарел, или наоборот — слишком новый и не факт, что перспективный? Легко ли будет найти по нему актуальные книги и уроки? Много ли таких неофитов будет вместе со мной обивать пороги ИТ-компаний через год-два? 

Опытным разработчикам тоже порой не хватает знания единственного языка программирования. В какой-то момент появляются специфические заказы и интересные вакансии, где крайне желательно владеть вторым (а то и третьим) языком. 

Помочь с выбором языка программирования призваны рейтинги их популярности. Однако тут легко обмануться. Каждый рейтинг составляется по своей методике и даёт разные результаты (порой — весьма неожиданные). В этой статье я постарался сделать более взвешенную оценку популярности языков программирования (далее — ЯП) по нескольким источникам. Подробнее о них и почему это важно — рассказываю ниже.

Индексы популярности

Всё началось с того, что мне попался на глаза свежий рейтинг актуальности ЯП, где в TOP 10 внезапно ворвался Delphi. Пытаясь разобраться в причинах его внезапной популярности в 2025 году, я стал искать методики составления таких списков и нашёл много любопытного. Как обычно, дьявол кроется в деталях. 

Индекс TIOBE — известный инструмент мониторинга, показывающий динамику интереса к разным ЯП. Он учитывает частоту поисковых запросов, связанных с ЯП. Для этого каждый месяц в Google, Bing, Yahoo! и Baidu отправляются запросы по определённому шаблону, чтобы отсеивать из выдачи мусор и корректно сравнивать статистические данные. Дополнительно в рейтинге учитывается число образовательных материалов о ЯП: количество видеоуроков на YouTube, книг на Amazon и упоминаний на Wikipedia.