Команда VK Cloud перевела интервью с Эйданом Гомесом, генеральным директором и соучредителем компании Cohere. Cohere — один из самых обсуждаемых стартапов в сфере ИИ на данный момент, но его ориентир чуть отличается от многих других. В отличии, например, от OpenAI, он вовсе не производит потребительские продукты. Вместо этого Cohere сосредотачивается на корпоративном рынке и создает ИИ-продукты для крупных компаний. Из интервью вы узнаете, в чем особенности такого подхода, что ИИ может, а чего не может, и что происходит на корпоративном рынке искусственного интеллекта.

При работе с облачной инфраструктурой важна не только гибкость использования ресурсов, но и возможность автоматизировать основные рутинные процессы. При разработке своих продуктов мы в команде VK Tech стараемся следовать именно этим принципам. В нашем продукте Dev Platform в рамках одной из возможностей реализовано автоматическое управление инфраструктурными ресурсами, необходимыми для разработки программного обеспечения — например, виртуальными машинами, Kubernetes-кластерами и прочими.

Меня зовут Виктор Горячкин. Я старший разработчик Dev Platform в VK Tech. В этой статье я расскажу о разработанном нашей командой решении для автоматизации развертывания инфраструктуры.

Развертывание корпоративной почты — задача «со звездочкой» для любого ИТ-специалиста. Надо гарантировать, что решение выдержит нагрузки, позволит подключить нужное количество пользователей, «не ляжет» в самый ответственный момент, не потеряет данные и позволит переехать с другой почтовой системы. Это непросто и выбора среди подобных инструментов немного — особенно с учетом того, что большие  компании часто выбирают развертывание почтовой системы в своей локальной инфраструктуре. 

Но варианты почтовых систем даже под такие запросы есть. Один из них — VK WorkSpace. 

Привет, Хабр. Меня зовут Павел Бухтияров, я руководитель команды Почта, VK WorkSpace. В этой статье я познакомлю вас с нашим решением, расскажу о его функциях и том, что находится «под капот» системы.

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

Меня зовут Александр Кириллов. Я СТО в компании Evrone. В этой статье я расскажу о наших предпосылках внедрения IDP, поиске вариантов реализации и объясню, почему иногда готовые решения не подходят.

Миллионы разработчиков пишут запросы PromQL и создают пользовательские дашборды Grafana для Kubernetes. И все используют одинаковые метрики из node-exporter, kubelet и kube-state-metrics. К сожалению, не все знают, как при работе с метриками обойти некоторые подводные камни.‍

Команда VK Cloud перевела статью, в которой автор разбирает ошибки в одном простом с виду запросе Prometheus для Kubernetes. Он должен возвращать сведения об использовании памяти пода:

Ало, как слышно?!

Я Иван Шафран, уже 4 года работаю с WebRTC на Android. В этой статье на примере VK Звонков расскажу, что можно сделать, чтобы улучшить качество сервисов для аудио- и видеосвязи. Обсудим достоинства и недостатки WebRTC. Расскажу, как работать с аудио, видео и режимом демонстрации экрана и какие есть варианты сбора статистики.

Безопасная разработка для современного IT — важнее некуда. Однако создание крупных решений становится сложнее, обновления — всё быстрее. Трудно отловить все баги, убедиться, что пользовательский опыт и ценные данные безупречно защищены. Поэтому всё чаще компании не только развивают внутреннее ИБ-подразделение, но и обращаются к сообществу — открывают программы багхантинга: предлагают опытным айтишникам помочь в поиске уязвимостей.

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

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

Работая над продуктом, мы поняли, что необходимо оценивать его техническое качество: считать размер SDK, тестового покрытия, скорость сборки и многое другое. Нам был нужен сборщик метрик качества кода. 

Я расскажу, как мы писали плагин для сбора метрик и с какими проблемами столкнулись. Вы узнаете, как устроен наш сборщик изнутри, и даже сможете потестить его в своём проекте.

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

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

Про байт‑код написано уже немало. Он везде, и никого этим не удивить: его генерирует компилятор, переупаковывает система сборки, «портит» обфускатор и изредка читают программисты. Естественно, для работы с байт‑кодом есть немало инструментов, которые используются в разных областях и на разных платформах. Среди них и ByteWeaver — инструмент для патчинга байт‑кода во время сборки, который может быть полезен разработчикам под Android.

Меня зовут Александр Асанов. Я Android‑разработчик в OK, Tracer, ByteWeaver. В этой статье я разберу, что такое байт‑код, как и зачем с ним работать, расскажу о ByteWeaver и покажу примеры работы с байт‑кодом.

Случается, ты просыпаешься и осознаешь: так больше продолжаться не может и нужно что‑то менять. Разные кодовые базы, избыточное легаси и нестабильность мешают пользователям получать удовольствие от общения в твоем приложении. И эта мысль подводит тебя к развилке: один путь ведет к сложному и долгому рефакторингу легаси за почти 10 лет, второй к не менее долгому, а, порой, более сложному процессу переписывания с 0. Но какой бы путь ты ни выбрал, в любом случае начинаешь испытывать азарт — предстоит большая Задача (именно с большой буквы).

Привет Хабр, меня зовут Федор Неживой, я ведущий программист‑разработчик в команде VK Мессенджера и сегодня расскажу вам, как мы перестраивали и обновляли один из крупнейших проектов в рунете. В статье будет боль, пот, реальный код и детали, как мы шаг за шагом пришли к масштабному обновлению, а потом внедряли то, что получилось.

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

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

«Битрикс24» — продукт, который позволяет клиентам удобно управлять бизнес-процессами и эффективно использовать доступные данные для глубокой аналитики. В последнем особенно помогает «BI Конструктор» — внутреннее решение, с помощью которого можно реализовывать даже самую сложную аналитику и прозрачно контролировать все метрики.

Меня зовут Александр Сербул. Я руководитель больших данных, высоконагруженных систем и машинного обучения «Битрикс24». В этой статье я расскажу, как мы строили «BI Конструктор»: какие требования предъявляли к решению, как решали возникающие задачи и что получили в результате.

Статья подготовлена по мотивам моего доклада на VK Cloud Conf 24. Вы можете посмотреть его здесь.

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

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

Главный минус — невозможность удовлетворить все потребности всех продуктов (особенно если речь идет о десятках и сотнях), в результате чего неизбежно возникают форки, собственные разработки и другие расхождения, постепенно отдаляющие продукты от единой дизайн-системы.
Выходит, что мультипродуктовые дизайн-системы работают, но с большими оговорками. Можно ли сделать так, чтобы они работали лучше?

Меня зовут Анастасия Кабалкина, я руковожу дизайном направления FinOps в VK Tech. В этой статье мы с вами разберем проблемы мультипродуктовых дизайн-систем и попробуем их решить небольшой доработкой архитектуры. А если не решить, то хотя бы минимизировать :)

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

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

Меня зовут Михаил Мосин. Я инженер-программист в ОК. В этой статье я подробно и пошагово расскажу, как зарелизить свое приложение на платформе ОК.

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

Интеграция RuStore Billing SDK в игры на движке Defold может быть немного сложнее, чем нативный вариант. SDK написан на Kotlin, и взаимодействие системы скриптинга Defold на Lua с нативным SDK требует использования JNI (Java Native Interface). 

Меня зовут Роман Пельмегов, я работаю разработчиком в RuStore.

В этой статье расскажу, как мы интегрировали платежные функции RuStore в Defold. Вы узнаете, как создать плагин и подключить нативные Android-библиотеки, чтобы упростить работу с SDK.

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

Во время работы над новыми экранами мне часто приходилось использовать множество различных иконок, разбросанных по всему проекту. Это навело на мысль: было бы здорово собрать все иконки в UI Kit в единственном экземпляре и использовать их только оттуда — по аналогии с тем, как это делают дизайнеры в Figma. И тогда я вспомнил об одной особенности Jetpack Compose.

Upd: Поиском по "Upd" можно найти все корректировки, внесенные в статью после публикации в результате жаркой дискуссии в чате Effector.

Меня зовут Андрес, я руководитель команды разработки внутреннего UI-кита ВКонтакте. А это ещё одна статья про инструменты управления состоянием. Сегодня мы не будем изобретать ничего нового, а поговорим про библиотеку Effector.

TL;DR

Почти год мы ВКонтакте пытались внедрить Effector, но пришли к выводу, что пока это достаточно сырая библиотека. Её недостатки зачастую проявляются сильно позже, чем хотелось бы, и, по нашему мнению, перевешивают достоинства… А последние местами преувеличены. Было больно осознавать количество потерянного времени, но, как говорится, лучше поздно, чем никогда.

В сети мало альтернативной информации про Effector, а действительно полезную трудно найти. Надеюсь, эта статья поможет немного исправить ситуацию.

(Внимание, под катом много картинок.)

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

Рассказываем об основных сложностях развития высоконагруженных ИТ-систем и способах их преодоления с помощью очередей сообщений на примере Tarantool Queue Enterprise.

Материал подготовлен по мотивам вебинара «Как создавать высокопроизводительные очереди сообщений с различной архитектурой». Вы можете посмотреть его здесь.