Нейросеть для обучения и выдачи информации появилась в Stack Overflow. ИИ чат-бота обучили на всех тредах платформы — бот обладает знаниями большинства реальных программистов, а не просто теоретическими выжимками и кучей готовых решений. Чат-бот умеет проектировать и рассуждать о коде, как команда живых разработчиков. Вы можете задать нейронке любой вопрос, и он предоставит полноценные рассуждения, развёрнутый ответ на базе вопросов форума.
Представлен симулятор тимлида, который управляет командой горе-программистов и должен успеть сдать проект в срок. Задача — сдать всё и не выгореть, когда полыхают дедлайны. Всё как в реальном офисе: бесполезные стендапы, куча созвонов с заказчиками, горы тасков и код-ревью. Нужно помогать команде сдать проект и при этом не поехать кукухой.
Ресурс Clone Wars содержит более ста клонов самых полезных сервисов. Например, с помощью этой библиотеки можно разобраться в устройстве самых хайповых программ и попрактиковаться в коде. Есть буквально всё, в том числе и клоны сервисов, ушедших из России: Notion, Spotify, YouTube, TikTok, Discord, Dribble, Dropboх и прочее. Детальный разбор устройства каждого сервиса, кода, архитектуры и функционала, а также советы по его воссозданию. Можно стащить использовать многие решения в своих пет‑проектах.
Яндекс Практикум добавил модули по работе с ИИ во все курсы ИТ-профессий для начинающих
Мы дополнили все курсы из каталогов «Программирование» и «Анализ данных» модулями по работе с ИИ, чтобы наши выпускники не просто «пользовались нейросетями», а превращали их в инструмент профессионального роста — и были востребованы на рынке труда.
Теперь вы сможете:
Разобраться, как устроены нейросети, освоить основы промпт-инжиниринга и научиться подбирать подходящие инструменты.
Использовать AI для быстрого освоения новых технологий и поиска решений.
Применять нейросети для генерации материалов, планирования проектов и оптимизации учебного процесса.
Научиться решать профильные задачи с помощью инструментов искусственного интеллекта.
Управление сложностью
Со временем, сложность проектов только растет. Какие бы мы изменения в коде не делали, переходили на новые фреймворки, базы, языки или подходы, алгоритмическая сложность (то что в бизнес логике) будет становиться только выше. Технические улучшения максимум могут убрать случайную сложность, когда мы выбрали неверный или не самый эффективный инструмент, но если с точки зрения логики нужно выполнить 30 разных сценариев, мы их запрограммируем в любом случае независимо от выбранных технологий.
Фактически все за что мы боремся когда занимаемся архитектурой проекта, это возможность сделать так, чтобы эта сложность росла как можно медленнее. Потому мы добавляем абстракции (когда без них больно), откладываем принятие ключевых решений и делаем много всякого разного. Естественно все это с учетом требований по производительности, надежности и т.п.
Ниже 5 рекомендаций, по тому, как определить, что выстрелит, а что можно отложить на потом и не сильно париться с кодом.
Грамотное управление состоянием
Говорил, говорю и буду говорить. За всем многообразием принципов и шаблонов, в самой глубине скрывается то как мы работаем с эффектами и процессами (состояния и переходы). Умение видеть это добро в коде и правильно с этим работать это ключ к тому, чтобы система оставалась поддерживаемой и устойчивой к ошибкам на самом нижнем уровне, когда мы на код смотрим как на код.
Изолированная сложность
В любом проекте есть какие-то вычислительные функции, которые работают как черный ящик и ни с чем не связаны. Сюда например, можно отнести все математические функции. Насколько принципиально если внутри грязь и копоть? Практически без разницы, такой техдолг изолирован и не растит общую сложность системы. Его можно воспринимать как библиотечный код, который пришел из зависимостей. Такой код можно переписать в любой момент, когда это станет нужным (например нужно повысить производительность) и с таким кодом отлично справляются LLM.
Приоритеты слоев
Ошибки на уровне формирования моделей и их связей, решают намного больше чем ошибки допущенные при выводе этих данных в api или на фронтенде. Вывод это всегда терминальная стадия, его результаты никак не используются в коде, а вот модели и то как организованы связи, это основа всего, что пронизывает все приложение на самом глубоком уровне. Если тут накосячить, страдать будем в каждой точке сталкивания. Можно сказать что порядок приоритета такой:
модели + структура базы => обработчики (контроллеры, сервисная история) => вывод (сюда же переводы и работа со строками)
Публичные контракты (API)
Все что выставляется наружу, будет иметь серьезные последствия в будущем. Хрен что поменяешь и поправишь. Поэтому на проектирование API нужно уделять внимание. А для этого нужно немного прокачаться, например, в том как делать REST API, знать про открытые и закрытые схемы, про принципы формирования ответов, обработки ошибок и всего такого (а они там есть). Это не хухры мухры, когда речь идет про проектирование каких-то сложных действий, авторизаций и других механизмов.
Отложенные решения
Хорошая архитектура не в том, чтобы заранее все продумать, а в том, чтобы отложить принятие решений до момента, когда у нас есть достаточно информации. Плохие архитектуры чаще всего страдают от преждевременных оптимизаций: усложнили, чтобы “на будущее”, а это будущее не наступило.
- Все, что можно поменять без боли - оставляем простым.- Все, что будет трудно поменять (API, модели, схемы БД, протоколы взаимодействия) - продумываем особенно тщательно.
Больше про разработку в моем телеграм-канале Организованное программирование
Мощный инструмент для Android-разработчиков
Retrofit — это библиотека, которая стала стандартом для работы с REST API в Android-приложениях. В нашей статье «Погружаемся в недра Retrofit» мы подробно разбираем, как использовать Retrofit максимально эффективно, чтобы упростить код и повысить стабильность приложений.
Что внутри?
Обзор основных возможностей Retrofit: от простой отправки запросов до работы с асинхронностью и обработкой ошибок.
Интеграция с OkHttp — что дает и как использовать на полную мощность.
Механизмы конвертации данных: Gson, Moshi и как кастомизировать парсинг.
Реальные примеры кода, которые можно сразу применять в своих проектах.
Советы по тестированию Retrofit-клиентов и особенностям работы с сетевыми вызовами.
Для кого статья? Для Android-разработчиков всех уровней, которые хотят улучшить качество сетевого кода и сделать его более поддерживаемым. Для тех, кто только пробует Retrofit и тех, кто хочет расширить свои знания и узнать внутренние тонкости работы этой библиотеки.
Ускоряем релизы и улучшаем качество с помощью Unleash
Сейчас в Альфа-Банке мы рассматриваем возможность внедрения фича-тоглов в наш проект и проводим исследование уже существующих решений. В рамках него мне удалось глубоко познакомиться с Unleash — самой популярной платформой для фича-тоглов на данный момент.
В статье «Разбираемся с Feature Toggle на примере Unleash» подробно объясняем ключевые понятия и возможности Unleash — от определения тоглов до сложных стратегий и сегментов. Демонстрируем реальные примеры кода и архитектурных подходов на Java и Spring и рассказываем о практических плюсах Unleash
Статья будет полезна Backend-разработчикам и тимлидам, DevOps и SRE-инженерам, менеджерам продуктов и качества и всем, кто планирует масштабировать систему с десятками и сотнями микросервисов, где требуется централизованный и удобный контроль остаточного риска внедрения новых функций.
Платформенная команда: секретный инструмент для масштабирования бизнеса
В ЮMoney мы используем стандартный фронтенд-стек — React, TS, Nest.JS — и микросервисную архитектуру с более чем 70-ю сервисами. По мере роста компании, количества команд и сотрудников в отделе нам понадобились единые стандарты в разработке и общий вектор развития. Эти потребности теперь закрывает платформенная команда.
Главная задача платформенной команды — создать фундамент для всей остальной разработки.
Преимущества такого подхода заключаются в том, что появилась единая стратегия технического развития всего отдела, больше возможностей для экономии ресурсов, стандартизации и контроля качества. Кроме того, этот подход способствует эффективному внедрению новых технологий во всех продуктах.
Платформенные команды эффективны, если перед вами стоит вопрос масштабирования технологий внутри компании. Такая команда снижает расходы на разработку, упрощает подбор сотрудников и помогает реализовывать техническую стратегию. Однако такой подход не для всех — он требует определённых масштабов и определённого уровня зрелости организации.
Подробнее о подходе, задачах команды и преодоленных трудностях — в статье на Хабре.
Представьте: у вас есть идея магазина. Через час у вас уже главная, каталог и корзина. Реально?
Да! Это вайбкодинг — новый способ писать код в потоке и быстро превращать идеи в прототипы.
13 октября на бесплатном вебинаре «Вайбкодинг без рутины: готовый проект за час» за 60 минут:
✔️ Развернём проект в Windserf без долгого сетапа
✔️ Сравним Copilot и GigaCode прямо в деле
✔️ Потренируемся в промптинге, чтобы код писать быстрее
✔️ Соберём интернет-магазин целиком в прямом эфире
⏰ Время: 16:00–17:00 (Мск).
📆 Дата: 13.10.2025.
👨🎓 Спикер: Кадочников Алексей — специалист в области фронтенд-разработки.
Лайфхак для начинающих разработчиков: уделите время изучению Английского
Да, да, учить не язык программирования, а нативный язык, сначала, или параллельно.
Это нужно чтобы получить преимущество на страте и забрать +100 к пониманию кода, документации, книг, статей и видосов по разработке. (И того что дают на выходе вайбкод-инструменты тоже.)
Очень многое завязано на английский в IT-мире, и названия железок, технологий и абстракций взялись не из воздуха, а как отсылки-аналогии на другие реальные объекты.
Например Server - это не только привычный нам сервер, а еще и официант. А Client - это клиент заведения. А заведение предоставляет Service.
Те же языки программирования например придумали англоговорящие люди, чтобы писать инструкции машинам на языке близком к английскому. (Понятно что сейчас можно вайбкодить на родном языке, при этом в мире IT по прежнему терминология завязана на English и в нашем тоже много англицизмов к которым мы просто привыкли.)
Еще, как бонус, говорят что это и для памяти и для здоровья ума полезно, так как изучение языков развивает и поддерживает когнитивную функцию. (Это уже не для начинающих, а для продолжающих скорее лайфхак 😁 )
Для того чтобы прокачаться в инглише много не надо. Банально можно поставить себе Duolingo и играться с ним по 10-15 минут каждый день. И этот простой шаг поможет не только изучению английского, но и программированию.
Я написал простой рассказ чтобы наглядно показать то что я имею ввиду, это может помочь, хотя конечно больше от вас зависит:
Let's start!
Sveta and Maxim walk in the city center.
"I'm hungry and want to eat," said Sveta.
"See, there's a cafe nearby; this cafe provides good service," said Maxim.
Maxim is a regular client of this cafe, and he likes its service.
They enter the cafe.
"Hi, Maxim," said the server Maria.
"Hi, Maria, menu please," said the client Maxim.
The server Maria gives them the menus.
Client Maxim orders a cake and tea.
Server Maria receives the order.
Client Sveta orders a hamburger and coffee.
Server Maria receives the order.
Then, server Maria passes the order to the cook Leonid.
Then, Leonid prepares the food for the clients.
After a while, server Maria passes the tea and cake to client Maxim.
And then, server Maria passes the coffee and hamburger to client Sveta.
Next, client Sveta eats her hamburger, and client Maxim eats his cake.
"I'm so happy, dear," said Sveta.
"I'm happy too, honey," said Maxim.
"Thank you for the good service, Maria," said client Maxim.
"You are welcome, Maxim," said server Maria.
The End :)
Делитесь своими мыслями и опытом в комментариях, хорошего вечера :)
P.S. Ну и сводите кого-нибудь в кафе на свидание, чтобы прочувствовать атмосферу метафоры, так лучше запоминается 😊
P.P.S. Проверка на внимательность: как зовут спутницу Максима, Света или Мария?
Zhipu AI выпустила GLM-4.6 с контекстом 200K токенов и производительностью уровня Claude Sonnet 4
Китайская компания Zhipu AI (Z.ai) представила GLM-4.6 — обновленную версию флагманской модели с расширенным контекстом до 200K токенов и улучшенными способностями в программировании, рассуждениях и агентских задачах. Модель показывает паритет с Claude Sonnet 4 при снижении потребления токенов на 15%.
Технические улучшения
GLM-4.6 построена на архитектуре предшественника GLM-4.5 с существенными оптимизациями обработки длинного контекста и генерации кода. Модель тестировалась на восьми публичных бенчмарках, покрывающих агентов, рассуждения и программирование.
Ключевые характеристики:
Контекст расширен со 128K до 200K токенов
Улучшенная генерация фронтенд-кода
Многошаговые рассуждения с использованием инструментов
Интеграция в поисковые и инструментальные фреймворки
Снижение потребления токенов на 15% относительно GLM-4.5
Результаты бенчмарков
На LiveCodeBench v6 модель набрала 82.8 балла против 63.3 у GLM-4.5 — существенный прирост. Claude Sonnet 4 лидирует с 84.5, но разрыв минимальный. На SWE-bench Verified GLM-4.6 показала 68.0 против 64.2 у предшественника.
Производительность в бенчмарках:
LiveCodeBench v6: 82.8 (GLM-4.5: 63.3, Claude Sonnet 4: 84.5)
SWE-bench Verified: 68.0 (GLM-4.5: 64.2)
CC-Bench: 48.6% win rate против Claude Sonnet 4
Снижение токенов: 15% относительно GLM-4.5
Компания расширила CC-Bench более сложными задачами, где человеческие оценщики работали с моделями в изолированных Docker-контейнерах, выполняя многошаговые реальные задачи от фронтенд-разработки до анализа данных.
Практическое применение
GLM-4.6 интегрирована в популярные агенты кодирования: Claude Code, Kilo Code, Roo Code, Cline. Модель доступна через Z.ai API platform и OpenRouter для разработчиков.
Для программирования:
Генерация фронтенд-компонентов с логичной структурой
Создание инструментов и автоматизация
Анализ данных и тестирование
Алгоритмические задачи
Ценообразование и доступность
GLM Coding Plan предлагает производительность уровня Claude по цене в 7 раз ниже с троекратной квотой использования. Модель доступна через веб-интерфейс chat.z.ai и API.
Варианты доступа:
Веб-интерфейс Z.ai с выбором модели GLM-4.6
API через Z.ai platform и OpenRouter
Локальное развертывание через vLLM и SGLang
Веса модели на HuggingFace и ModelScope
Сравнение с конкурентами
GLM-4.6 показывает конкурентоспособность с DeepSeek-V3.2-Exp и Claude Sonnet 4, но отстает от Claude Sonnet 4.5 в программировании. Модель опережает китайские аналоги при использовании на 30% меньше токенов.
Конкурентная позиция:
Паритет с Claude Sonnet 4 в реальных задачах
Превосходство над китайскими альтернативами
Отставание от Claude Sonnet 4.5 в кодинге
Токен-эффективность выше на 15-30%
Архитектура и развертывание
Модель поддерживает современные фреймворки инференса для эффективного локального развертывания. Доступны базовая и чат-версии для различных сценариев использования.
Всесторонние инструкции по развертыванию опубликованы в официальном GitHub-репозитории с примерами интеграции и конфигурации.
Оценка реального использования
Компания подчеркивает, что реальный опыт важнее лидербордов. Траектории выполнения задач из CC-Bench опубликованы на HuggingFace для исследований сообщества, обеспечивая прозрачность оценки.
Если материал был полезен, поставьте, пожалуйста, плюс — мы стараемся выбирать для вас только самые актуальные и интересные новости из мира ИИ.
Разбираю статью про обучение с подкрплением для самых маленьких и генерацию ответов
Все мы знаем, что большие модели любят учиться на готовых ответах. Но, угадай что? Готовых ответов у нас нет. Они либо дорогие, либо спорные, либо вообще непонятно какие. Представь, что у тебя есть только ты сам, твои черновики и пара свободных вечеров. Ну что, будем учиться на своих же косяках?
Вот для этого придумали Compute as Teacher (CaT). Работает оно так:
Пользователь кидает запрос. Ну там: «объясни квантовую физику бабушке».
Модель честно пишет сразу несколько версий ответа. Каждая по-своему кривая, но иногда попадаются удачные куски.
Другая копия этой же модели собирает из них «лучший хит» — вроде плейлиста «самое ок» из твоих старых песен.
Потом мы сравниваем все черновики с этим «финальным шедевром» и решаем: «ага, вот это было ближе, а это лучше забыть как страшный сон».
Модель сама делает выводы и в следующий раз уже тупит чуть меньше.
В итоге получается странная штука: модель учится без учителя, проверяя сама себя. Как если бы школьник писал 5 вариантов решения задачи, потом сам делал «сборку Франкенштейна» из них, и именно её принимал за эталон. А дальше наказывает себя за плохие черновики и хвалит за удачные.
И что самое весёлое — это реально работает. Без людей, без правильных ответов, без пафоса. Просто куча вычислений, которые модель тратит на то, чтобы спорить сама с собой и становиться чуть умнее.
Если коротко: CaT — это как спорить с самим собой в душе, только полезно
Ссылка на статью у меня в блоге, потому что у меня карма маленькая и тут я не могу всё опубликовать
—————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
Я размышлял над созданием инструмента для вайбкодинга и вот что я понял:
Вайбкодинг — это менеджмент.
Со всеми его плюсами и минусами.
У менеджмента фокус на управление.
У разработки фокус на конструирование.
Для менеджмента нужны прокачанные скилы общения (говорить, слушать, писать, читать на человеческом)
Для разработки нужны прокачанные скилы разработки (говорить, слушать, писать, читать на программном)
И сейчас такое время когда чтобы преуспеть «разработчики» учатся говорить на человеческом, а «менеджеры» учатся говорить на программном.
Всего один час — и вы тратите на облако меньше 💸☁️
Облачная инфраструктура растет, расходы тоже, а следить за ними становится все сложнее... Мы вас понимаем — и зовем на вебинар, где расскажем, как сэкономить без сокращения ресурсов и мощностей.
О чем поговорим на встрече:
Покажем реальные кейсы, как управлять расходами в личном кабинете Cloud.ru.
Как перестать считать траты вручную — и начать автоматически.
Как настроить уведомления и лимиты, чтобы быстро реагировать на превышения.
Расскажем, как найти неэффективные ресурсы и сократить их использование.
Как настроить подробную аналитику, тестирование и фильтры.
Как сэкономить еще больше, если использовать бесплатные возможности Evolution free tier 😉
📅 Когда? 7 октября в 11 по мск.
📍Где? Онлайн. Регистрируйтесь на вебинар по ссылке →
А пока ждем встречи, спросите у AI-помощника Клаудии, как оптимизировать ресурсы в вашем облаке — найти Клаудию можно в личном кабинете Cloud.ru.
Нам нужно сделать что-то вроде IT-профсоюза чтобы защитить людей от произвола работодателей, нанимателей и продавцов курсов.
Так как дело обстоит сейчас - никуда не годится.
IT-специалистов за людей не считают, независимо от стажа и ранга, будь ты junior, middle, senior или teamlead, ты сталкиваешься с проблемами при трудоустройстве.
Понятное дело что мы уже попривыкли к такому обращению, но разве нас это устраивает?
Меня - нет.
Причем страдаем не только мы - трудяги, но и сами наниматели и работодатели, потому что все мы в одной лодке.
Сейчас на рынке труда разработчики грызутся между собой за кость щедро брошенную со стола "хозяина". Ситуация напоминает описанную в теории игр "Дилемму заключенных"(там где про равновесие Нэша), когда напарники действуют друг-другу и себе в минус, и выигрывает всегда 3-я сторона, из-за того что напарники не имеют возможности общаться друг с другом.
Но мы то не заключенные, мы то слава богу свободные!
И у нас есть возможность общаться друг с другом и договариваться для получения обоюдовыгодных результатов.
Я сам технарь и пару десятков лет прожил как интроверт, замкнутым сам в себе, одиночка. Не надо так.
Мы можем общаться и достигать совместных успехов, защититься от произвола нанимателей и перестроить этот рынок труда. Тем более сейчас, когда он на пике своей несостоятельности.
P.S. если такое объединение уже есть - дайте ссылку, я впишусь
P.P.S не знаю что точно надо делать, но решил что буду что-то делать, телеграм канал лишнее таких уже куча а воз и ныне там, очевидно чего-то не хватает, пока можно обсуждать здесь
Стоит ли в тексте статей про Docker переводить "image" как "образ"?
Какой термин вам ближе и понятнее?
Авторы из AI Institute, University of Montreal, Princeton University. Статья внушает доверие. Она также подтверждается моими собственными наблюдениями
Ребята говорят о экономии токенов на модельках, 46% меньше потребление ресурса + как следствие ускорение
Суть в том, что модели много рассуждают об известных фактах. Например, если модель попросить решить уравнение с геометрической прогрессией. Она сначала его выведет, а потом будет решать. И так шагов может быть много. У больших моделей есть привычка «думать вслух». Они, когда решают задачу, раскладывают всё по шагам — иногда очень длинно. Это классно для качества, но плохо для скорости и денег: чем больше токенов, тем дороже и медленнее
Пример на прогрессии
Ты просишь модель: «реши уравнение с геометрической прогрессией»
Что она делает?
Сначала начинает выводить саму формулу суммы прогрессии: пишет длинное рассуждение, как она получается.
Потом подставляет числа.
Потом делает вычисления.
И только в конце даёт ответ.
Каждый раз она повторяет эту историю, как будто «заново изобретает велосипед».
Что предлагают авторы статьи
Ребята говорят: зачем каждый раз заново выводить одно и то же? Давайте выделим такие повторяющиеся шаги в маленькие «карточки-подсказки» (они называют их behaviors).
Например, поведение:
«Сумма первых n членов геометрической прогрессии = (a₁(1–qⁿ)) / (1–q)».
Теперь, когда модель решает задачу, мы ей сразу даём эту карточку. Она не тратит сотни слов на то, чтобы вывести формулу, а сразу использует её.
Почему это полезно
Экономия ресурсов: в экспериментах до 46% меньше токенов.
Ускорение: модель тратит меньше времени на текст.
Качество не падает, а иногда даже лучше — потому что меньше места для ошибок.
Итог
Классика: модель сама думает длинно, это дорого и долго.
Новый подход: мы даём ей готовые «кирпичики рассуждений» (behaviors), она использует их и отвечает быстрее.
В общем виде: решение = текст задачи + набор подсказок.
Тут можно формулы привести со всякими условными вероятностями. Душнить не буду. И так надо форточку открывать
Ссылка на статью, как обычно, в моём канале
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
Приглашаем на вебинар, посвященный вопросам перехода на отечественную Java-среду исполнения. Обсудим, как указы №166 и №250 и приказ Минцифры №21 задали курс на импортозамещение и определили классы ПО для замены.
Поговорим о рисках зарубежных решений, требованиях к безопасности и роли среды исполнения как ключевого слоя ИТ-систем
Кому будет полезен вебинар:
• Директорам по информационной безопасности
• Техническим директорам
• Директорам по ИТ
• Руководителям отдела программного обеспечения
• Разработчикам информационных систем
Вебинар проведет:
Роман Карпов, Директор по стратегии и развитию технологий Axiom JDK, Руководитель ИБ-комитета АРПП "Отечественный софт", Руководитель технического комитета АНО "Открытый код", Советник Министра цифрового развития по вопросам системного ПО, председатель ЦКР по управлению ИТ-инфраструктурой
Когда: 01 октября 2025 г.
Во сколько: 11:00–12:30 по мск
Формат: Онлайн
Участие: Бесплатное (нужно предварительно зарегистрироваться)
Всех приветствую! Видел ТГ бота который присылает аварии(инциденты, ДТП) сразу как то их создали на яндекс картах в определенных городах! Попытался сделать такого же, опыт в разработке ботов имеется, но увы я ни как не могу достать из яндекса инфо о ДТП, перерыл все их АПИ, отрисовать на карте слой с ДТП могу, а вот получить данные для обработки ни как вообще! Может кто знает какой то секрет? Буду благодарен любой помощи!
RCS (Rich Communication Services) — это эволюция SMS/MMS, протокол, который мобильные операторы и Google продвигают как «мессенджер по умолчанию». Если SMS = plain text, то RCS = полноценные интерактивные сообщения с кнопками, каруселями, картинками, видео, QR-кодами и встроенной аналитикой.
Ключевые моменты
Протокол: работает поверх IP, а не через старую SMS-сеть, но доставляется в «стоковое» приложение сообщений (Google Messages, Samsung Messages).
API: доступ через Google Jibe Hub (фактически, центр маршрутизации), плюс нужно согласование с операторами. Прямо в код «в лоб» не залезешь — всё через провайдеров/агрегаторов.
Безопасность и доверие: каждая компания-отправитель проходит верификацию бренда, чтобы на экране у пользователя сообщения выглядели не как «спам», а с логотипом и цветами бренда.
UX: разработчик не отправляет просто текст, а собирает карточку или интерактив через шаблон/SDK → пользователю приходит сообщение, похожее на push или мини-приложение внутри SMS.
То есть RCS = «SMS на стероидах», но с кучей бизнес- и бюрократических ограничений. Главная боль — доступ к API и вся регуляторка, поэтому на рынок вышли «коробочные» сервисы (как Smobi), которые берут эти сложности на себя
Кодик и ссылки у меня в канале
——————
Менеджер? Давай сюда!
Ищи работу здесь
Технологии и архитектура
