Привет, меня зовут Константин, последние пять лет я возглавляю команду RnD. Мы развиваем нашу внутреннюю Frontend-платформу, а до этого я занимался разработкой сервисов для нашего БЮ, Почты и Облака. В статье описан типичный пример моей задачи по созданию продукта: как мы с нуля создавали сервис VK Доска.

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

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

Привет, Хабр! Меня зовут Георгий Семёнов, в VK я занимаюсь разработкой в команде инфраструктуры рекомендательных систем, а в Университете ИТМО начинаю свой аспирантский путь в области децентрализованных коллаборативных сред.

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

Представьте, что в основе вашего коммерческого продукта используется компонент с исходным кодом, который написан на смеси языка С и самописного ассемблера. Из-за слабой детерминированности поиск репродьюсеров сложен, а без репродьюсера мейнтейнер проекта заявляет: «Сделайте так, чтобы я про вас больше не слышал». Я расскажу, как мы построили процесс активной поддержки LuaJIT в СУБД Tarantool, сократили количество инцидентов в продакшене, сократили затраты на бэкпорт патчей из основного проекта и какую роль во всем этом сыграл фаззинг и его специфика.

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

В СУБД Tarantool используется LuaJIT в качестве языкового рантайма, но в Tarantool используется не оригинальный проект, а его форк. Я расскажу, как мы прошли путь от пассивного использования кода LuaJIT к процессу поддержки форка, с которым количество инцидентов на продакшене установилось около нуля, сократились усилия по бэкпортингу патчей из основного проекта, а основной проект получил активных контрибьюторов.

Я рассмотрю специфику работы с проектом исходного кода на примере LuaJIT, расскажу, как устроено тестирование в нашем форке и какую роль там играет фаззинг. Расскажу о специфике фаззинга LuaJIT и о том, каких результатов мы в этом достигли за последние два года.

Привет, Хабр! Меня зовут Андрей Белов, я работаю в команде стриминг-технологий AI VK. Сегодня хочу рассказать, как мы построили систему, которая в реальном времени обрабатывает сотни тысяч событий в секунду и превращает их в персонализированные рекомендации для десятков миллионов пользователей. Благодаря этому люди встречают больше интересной для себя информации, а авторам легче находить свою аудиторию. Поговорим про ProfileStream (часть Discovery-платформы) — нашу систему для расчёта пользовательских эмбеддингов, про то, как мы боролись с терабайтами трафика, и какие простые, но изящные инженерные решения помогли нам справиться с нагрузкой

Меня зовут Александр Вирочкин, я руковожу командой инфраструктуры мини-приложений ВКонтакте. За последние два года мы мигрировали один из ключевых сервисов с PHP на Go — путь выдался непростым, но, уверен, наш опыт будет полезен многим. Не все получилось с первой попытки: мы столкнулись с типичными и не очень проблемами, зато смогли по-настоящему оценить роль внутренней PaaS-платформы и экспертизу коллег.

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

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

Если вы работаете UX-исследователем в B2B-направлении и ваши респонденты — разработчики, то скорее всего вам знакомо это ощущение: приходите поговорить про пользовательский опыт, а в итоге погружаетесь в дебри технической документации. Манифесты, подписи, Bundle, API, ключи, PEPK… Страшно? Немного. Но выжить — реально.

Меня зовут Татьяна Лескова, я старший UX-исследователь в RuStore — магазине мобильных приложений, где пользователи — не только те, кто их устанавливает, но и те, кто публикует. Поэтому среди наших респондентов — разработчики, тестировщики и другие технические роли, которые выкладывают, развивают и монетизируют свои приложения на нашей платформе. Иногда это команды из крупных компаний, иногда один инди-разработчик, совмещающий все задачи.

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

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

Этот текст будет полезен как UX-исследователям без CS-бэкграунда, так и тем, кто работает с разработчиками бок о бок и помогает им строить качественные B2B-продукты.

Привет, Хабр! Меня зовут Александр Петрушин, я старший разработчик в VK Tech, и сегодня хочу рассказать о нашем опыте создания технического радара.

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

Так родилась идея создать собственный технический радар — инструмент, который помогает командам лучше ориентироваться в технологическом ландшафте компании. В статье расскажу, зачем он нам понадобился, как мы подошли к сбору и визуализации данных, какие технические решения приняли и какие выводы сделали в процессе. Покажу, как мы использовали GitLab API, LLM и немного магии, чтобы всё заработало почти без ручной работы.

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

Привет, Хабр! Меня зовут Михаил Полукаров, я занимаюсь разработкой Desktop-версии корпоративного супераппа для совместной работы VK Teams.

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

В этой статье я покажу, как сделать универсальную фабрику объектов, покрывающую большую часть потребностей, следующую принципам DRY (Don’t Repeat Yourself), а также как можно использовать некоторые «фишки» новых стандартов С++. 

Всем привет! Меня зовут Евгений Пищик, и сегодня я хочу поделиться с вами опытом разработки метода переноса нейросетевых атак, над которым я работал в рамках мастерской по сервисам и платформам ИИ в Инженерно‑математической школе НИУ ВШЭ и VK.

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

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

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

Меня зовут Максим Кокряшкин, я занимаюсь разработкой языковых рантаймов в Tarantool. Это решение класса middleware, разрабатываемое VK Tech, сочетающее в себе базу данных in-memory и application-сервер. Как раз таки наш application-сервер, который позволяет писать логику и хранимые процедуры, работает на LuaJIT

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

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

В прошлом году одним из направлений работы R&D команды в AI VK были энкодеры текстов: модели, которые преобразуют любой текст, от анекдота до официального запроса в техподдержку, в векторное представление — эмбеддинг. Эмбеддинги отражают важные свойства текста, его семантику. Все энкодеры в NLP можно условно разделить на две группы:

•Pre‑train‑модели (BERT, RoBERTa, DeBERTa).
Учатся основным языковым закономерностям, но не умеют явно создавать единый эмбеддинг для всего текста и требуют дообучения под конкретную задачу.

•Энкодеры текстов (SBERT).
Сразу выдают готовые семантические эмбеддинги — используются в FAISS, Milvus, других векторных БД. Поверх векторного представления можно применять классические алгоритмы ML. Для оценки схожести текстов просто считаем косинусную близость между эмбеддингами.

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

Привет, Хабр! На связи Артём Камыш, руководитель платформенной команды VK Cloud. Сегодня расскажу о том, как мы сделали систему, которая помогла:

• уменьшить количество инцидентов;
• сократить время их устранения;
• ускорить постинцидентный анализ;
• стандартизировать процессы разработки для 120+ проектов.

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

Долгие годы вендоры работали над тем, чтобы сделать UI в SIEM удобным, эффективным и простыми для аналитиков SOC, а теперь аналитики хотят код, git, vim. Упс.

Привет! Меня зовут Павел Таратынов, я лид аналитиков L3 в VK SOC, и в этой статье я расскажу, почему и зачем мы перешли на Detection as code, какие бенефиты от этого получили и стоит ли игра свеч. Поехали!

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

Привет, Хабр! Меня зовут Андрей Капустин, я менеджер продукта в компании VK Tech. Для построения систем хранения и обработки данных по объектам мы часто используем различные СУБД, которые объединяем в большие геораспределенные кластеры. Кластер СУБД содержит данные, необходимые для функционирования Mission Critical процессов, поэтому нам необходимо гарантировать постоянную доступность, обеспечить отсутствие потерь и минимизировать время предоставления данных по запросу.

Привет, Хабр! Меня зовут Роман Мельник, я фронтенд-разработчик во «ВКонтакте для Бизнеса». Наша команда создаёт инструменты, которые помогают владельцам сообществ управлять и развивать свои проекты. Сегодня я расскажу про Dependency Injection (DI) через библиотеку Tsyringe.

Почему это важно? Крупные проекты сталкиваются со следующими проблемами: разрастающимся глобальным стором, сложностями тестирования, масштабирования и переиспользования кода. Внедрение зависимостей помогает решить эти вопросы, делая код гибким и управляемым. На практике это выглядит гораздо интереснее. Давайте разберёмся!

Начнём с архитектурных принципов и паттернов.

Привет, Хабр! На связи Олег Оболенский, я руководитель направления проектирования и разработки VK Tech. В компании я отвечаю за разработку корпоративного ПО, а мои команды также оказывают комплекс профессиональных услуг по адаптации наших решений к бизнес-требованиям заказчиков. Мы реализуем облачные и гибридные проекты любой сложности и масштаба, переносим данные, поддерживаем наши сервисы, помогаем оптимизировать затраты на ИТ, управлять виртуальной инфраструктурой. Из каждого сложного внедрения мы стараемся выносить пользу, чтобы обогащать продукты новыми возможностями. Кейс, про который мы сегодня расскажем, будет на стыке работ сразу нескольких подразделений.

Привет, Хабр. Меня зовут Марат Исаев. В этой статье я кратко рассмотрю устройство самописного микрофреймворка и его применение для написания приложения-планировщика, чтобы вы могли написать свой фреймворк, для своих приложений. Подчеркну: статья образовательная и не охватывает enterprise-разработку.

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

Привет! Меня зовут Алексей, я работаю Android-разработчиком в Облаке Mail. Наше приложение выполняет важную задачу — хранит воспоминания пользователей. Для этого необходимо уметь правильно работать с файлами в фоне, чтобы не только надёжно хранить те самые воспоминания, но и быстро их загружать, редактировать и делиться. В этой статье я расскажу о том, как мы пришли к нашим современным методам фоновой работы в Android.