Есть окружность с центром O, а также N, множество вершин многоугольника, вписанного в фигуру. Каждая вершина может быть расположена на длине окружности случайным образом. Нужно определить вероятность, что при случайном наборе N центр O будет внутри этого образованного многоугольника.
Задача
Напишите модель симуляции, например, на Python, вычисляющую вероятность, что случайно сгенерированный вписанный в окружность многоугольник будет заключать в своей площади центр O.
Как подойдете к задаче? Напишите свое решение в комментариях и сверьтесь с алгоритмом в Академии Selectel.
Итак, поскольку бизнес, похоже, до сих пор не верит, что ему, по-прежнему, не обойтись без живых и толковых разработчиков, и предается влажным мечтам о тотальном вайб-кодинге лично потугами стейкхолдеров и продакт-оунеров (ахаха!), то я пока просто поделюсь несколькими реальными практиками, которые мне удалось применить в работе над пет‑проектами и которые я, как техлид, могу смело предложить для внедрения в небольших командах.
Затем, в следующих постах, я постараюсь объяснить доходчиво, почему Вам, уважаемые CEO и кофаундеры, глупо ждать очередного прорыва, -- лучше нанимайте хороших специалистов, пока хайп не сдулся (завтра ноябрь, але!). Без них "волшебный черный ящик" не заработает вам ничего.. ;)
Начну с банального рецепта, применимого моментально к любому индивидуальному разработчику в его повседневной деятельности (одной-двумя командами и без вложений!).
Первый шаг вроде бы очевиден, это конечно же установить плагин для IDE и привыкнуть к нему. Но загвоздка есть сразу -- придется прям выбирать и пробовать, ибо их слишком много, а единственная реально юзабильная их функция -- это автодополнение. Поэтому просто выберите такой, чтобы хорошо это делал в вашей любимой среде разработки и можно было переключаться между локальными и облачными API.
Но, когда привык и наигрался, то куда дальше? Где этот реальный буст в конце-то концов?
Будем искать! И вот что я пока нашел, однозначно полезного и перспективного:
Шаг второй: LLM CLI tool — это что‑то вроде, например, aichat, установленного локально для вашей консоли. Он приносит все возможности LLM прямо в командную строку, опираясь на мощь нативных Unix‑пайпов — вот где начинается настоящая магия. 😉
Например, вместо того чтобы тужится с shell-синтаксисом, ты можешь мгновенно зашорткатить себе быстрый запуск следующего шага:
$ aichat -e create bash script to launch docker container with qwen-code and current or specified folder mounted to workdir as volume
Шаг третий: Coding Agent — попробуйте, наконец, полноценного агента. Мне кажется очевидным, что агенты должны работать в изоляции, поэтому я настоятельно рекомендую подходить к снаряду сразу через контейнер. Мой текущий выбор — Qwen‑code в Docker, который я запускаю с любым локальным каталогом, смонтированным как volume, связанным с рабочей директорией.
Qwen‑code отлично работает в связке с открытой рядом IDE — позволяя плавно переключаться между ручным кодингом и LLM‑ассистированным процессом разработки.
2000 запросов в день бесплатно! ;)
Оба инструмента уже описаны на Хабре. Но, поскольку инструментов великое множество -- хотел бы обратить ваше внимание именно на эти. Спасибо.
В следующих постах, возможно, расскажу подробнее о часто возникающих кейсах и следующих шагах, вроде добавления MCP.
Сегодня мы решили обойтись без банальных страшилок про призраков и ведьм и придумать кое-что более пугающее. Герои наших историй столкнулись с настоящими цифровыми кошмарами — взломом и потерей данных.
Почитайте, чтобы немного пощекотать нервы, а затем пройдите небольшой тест. Благодаря нему сможете оценить, насколько хорошо вы разбираетесь в надежном хранении. Всем, кто не испугается, подарим промокод на 1 000 бонусов в панели Selectel.
Обсудили контуровцы: Антон Нечуговских, ведущий инженер-программист в 24 года, и Никита Хубаев, начинающий инженер-программист в 36 лет.
Сеньор в 25 лет вызывает недоверие у коллег из-за своего возраста
Сеньор в 24: Открытые и адекватные люди скорее делают вывод о тебе по тому, как ты с ними взаимодействуешь, а не по тому, сколько тебе лет. Но с недоверием да, иногда сталкиваюсь. Я поэтому и перестал брить бороду 😁 и это не шутка.
Джун в 36: Я раньше работал в продажах, и примерно в 23 года уже был директором магазинов. Старшие коллеги воспринимали это нормально. Важно то, как ты себя позиционируешь в команде, насколько развиты у тебя харды и софты. Если с этим всё в порядке, то и команда это чувствует.
Пользы для продукта или команды от 35-летнего джуна больше, чем от 25-летнего сеньора, из-за большего жизненного опыта у джуна
Джун в 36: Да, пользы чуточку больше, но это связано не с возрастом, а с тем, какой у тебя грейд. Если ты сеньор, то занимаешься внутри команды больше архитектурными задачами, и то время, которое мог бы потратить на разработку продукта, тратишь на наставничество, помощь в написании кода и код-ревью. А будучи джуном в 35 лет ты концентрируешься на том, чтобы писать код и в итоге приносить больший пользовательский опыт.
Сеньор в 24: Хм, ну работа же не заканчивается написанием кода. 😉 Какое-то видение появляется, и из-за того, что есть сеньорский опыт и технический бэкграунд, ты это видение применяешь в нужном направлении. Уже многое умеешь, но при этом есть альтернативный вижн по сравнению с коллегами, которые намного старше тебя. Можешь на их языке с ними общаться и доносить до них что-то новое.
Джун в 36: Некоторые люди в командах не могут занимать должность мидла, хотя с технической стороны они уже глубокие сеньоры. Считаю, лучший грейд — это мидл+.
Джуну в 35 сложнее найти работу, чем джуну в 25
Сеньор в 24: Думаю, что да. Увы, эйджизм никуда не делся. 🤷♂️ Скорее всего, эйчар отметит в тебе целеустремлённость, но поставит под сомнения перспективы.
Джун в 36: Я стал разработчиком после 30 лет, и самое сложное было впервые оказаться на собеседовании. Но отмечу то, что, вероятно, в этом возрасте у тебя будет всё хорошо с софтами, и это твоё преимущество. А для работодателя знак: если такой кандидат осмелился пойти в айти после тридцати, то, скорее всего, в нём есть настойчивость и ответственность, которая и в работе обязательно проявится.
Джуны сталкиваются с излишним контролем на работе, даже когда им 35
Сеньор в 24: Считаю, что джуна не надо сильно контролировать, пусть сам копается, выдаёт результат, а дальше можно будет подкорректировать.
Джун в 36: Согласен, но смотря какие задачи ты даёшь джуну. Если задача от бизнеса, то нужно будет разделить с ним ответственность. В целом, не надо контролировать, как джун пишет код, при этом всё-таки проводить код-ревью, чтобы помогать ему писать код правильно, и следить за сроками.
Не стоит начинать карьеру в IT после 30, лучше искать что-то другое
Сеньор в 24: Средний возраст ребят в IT меньше 30 лет, и когда ты находишься в обществе людей старше тебя, то и сам как будто бы быстрее взрослеешь. В другую сторону работает так же: если вокруг все младше тебя, ты молодеешь и наполняешься этой энергией.
Джун в 36: Поддерживаю! Если ты видишь в себе потенциал, тебе это интересно, обязательно попробуй. Но не требуй от себя много, например того, что добьёшься чего-то в короткий срок. Отнесись к этому, как к пути. Лучше уж после 30, чем после 40. Но даже если после 40 тебе это интересно — здорово! Я знаю людей, которые учились и в 60 лет, проходили стажировки. Да, не все из них трудоустроились, но это был вызов для них и новый опыт.
Сеньор в 24: Менять свой путь после 30 — сложно, я восхищаюсь теми, кто это делает. 👍
За последние месяцы в Практикуме появилось несколько новых курсов и дополнений в текущих программах. Делимся подборкой, чтобы вы точно ничего не пропустили.
Новые курсы
«Нейросети для бизнеса»— 10 недель о том, как применять нейросети для оптимизации процессов, сокращения расходов и роста прибыли. Курс подойдёт руководителям, предпринимателям и специалистам, которые хотят внедрять ИИ-решения в свои проекты и команды.
«Rust для действующих разработчиков»— программа для тех, кто хочет перейти на Rust или сделать его основным стеком. Разберём многопоточность, асинхронность, API, WebAssembly, принципы владения и заимствования, async/await и FFI. После курса сможете создавать надёжные и безопасные продакшн-решения.
«Обработка естественного языка (NLP)»— двухмесячный курс для специалистов по Data Science, ML и DL. Научим применять NLP для работы с большими данными, интегрировать технологии в приложения и сервисы — от чат-ботов до инструментов анализа текстов.
«Руководитель направления DevOps»— программа для тех, кто хочет совмещать техническую экспертизу и управление командой. Поможет стать «играющим тренером» — специалистом, который одинаково уверенно разбирается в технологиях и менеджменте.
Обновления в курсах
«Управление командой».Появился новый максимальный тариф. Помимо всех материалов расширенного формата, в него добавлен модуль по критическому мышлению и курс «Нейросети для работы». Формат для тех, кто хочет развиваться на стыке управленческих и технологических компетенций.
«Технический директор — CTO». Теперь с двумя новыми тарифами — расширенным и максимальным. Курс помогает структурировать опыт, освоить новые инструменты, научиться строить антихрупкие команды, проводить технический аудит и выстраивать IT-стратегию. А ещё — завести полезные знакомства с действующими СТО из крупных компаний.
«Системный администратор».В расширенном тарифе добавлены три дополнительных месяца обучения — это шесть новых тем по Windows и шесть практических проектов для портфолио. Курс охватывает востребованный стек технологий и реальные задачи системных администраторов.
Экс-инженер Nvidia Чип Хьюен (Chip Huyen, исследовательница ИИ, которая раньше работала над платформой NeMo в Nvidia и преподавала машинное обучение в Стэнфорде) считает, что неважно, что именно вы создаёте, главное — пройти путь от идеи до готового решения, которым сможет воспользоваться кто-то другой.
По словам Хьюен, строить что-то с нуля могут и должны не только инженеры. Например, даже начинающие пользователи без технического образования благодаря ИИ-ассистентам для кодинга могут создавать рабочие проекты. «После этого они становятся гораздо увереннее в себе и лучше понимают, как работает ИИ», — пояснила Хьюен.
Тем, кто не знает, с чего начать, Хюен предлагает простое упражнение: в течение недели записывать всё, что раздражает — от рутинных задач до медленных процессов. А потом выбрать одну проблему и попробовать её решить. При этом важно не ограничиваться только практикой. «Учиться только через проекты — всё равно что осваивать новый язык, просто разговаривая», — отмечает Хьюен. Чтобы разобраться в инструментах, стоит изучить теорию — выбрать учебный курс, книги или структурированную программу.
Хотите выяснить, где учиться IT? В экосистеме Хабра есть маркетплейс курсов на Хабр Карьере, на котором собраны сотни онлайн-обучений в самых разных специализациях: программировании, аналитике, дизайне, менеджменте и других. Чтобы пользователи могли проверить качество курсов, там показаны отзывы от тех, кто уже прошел обучение — изучайте и выбирайте лучшее для себя.
17 открытых репозитариев, чтобы выучить Python с нуля:
30-Days-Of-Python — пошаговый курс на 30 дней: синтаксис, типы, функции, ООП, файлы, модули, мини-проекты и задания с решениями;
Python Basics — вся база и примеры по основам для новичков;
Learn Python — конспект тем с наглядными примерами и ссылками; удобно как быстрый справочник и повторение;
Python Guide — лучшие практики: окружение, управление пакетами, стиль, тестирование, деплой, инструменты;
Learn Python 3 — понятные ноутбуки и упражнения по Python 3. Лучший репо для самостоятельной практики;
Python Programming Exercises — 100+ задачек по базовым темам с решениями; Coding Problems — алгоритмические задачи, разбитые по темам и сложности. Идеально для подготовки к собеседованиям;
Новое видео с нашей Конференции Luxms, теперь с технологической сессии. Илья Гурешидзе @IlyaGureshidze начальник отдела разработки Luxms BI рассказал о магии вне Хогвартса внутри движка.
Одна из сильных сторон Luxms BI – гибкость клиентской части. Связка JSON + React дает предсказуемое поведение, быструю сборку и легкую доработку интерфейсов – без необходимости лезть в «ядро» или переписывать все с нуля.
Для удобства разработчиков в системе есть специальный проект – bi-magic-resources (BMR). Это проект на React, где можно разрабатывать интерфейсы, хранить наработки в GIT, вести совместную разработку, кастомизировать сборку и запуск, подключать свои библиотеки и переиспользовать уже готовые компоненты заказчика. С ним удобно разрабатывать, тестировать и пробовать новый функционал, не мешая основной ветке разработки.
Нейросеть для обучения и выдачи информации появилась в Stack Overflow. ИИ чат-бота обучили на всех тредах платформы — бот обладает знаниями большинства реальных программистов, а не просто теоретическими выжимками и кучей готовых решений. Чат-бот умеет проектировать и рассуждать о коде, как команда живых разработчиков. Вы можете задать нейронке любой вопрос, и он предоставит полноценные рассуждения, развёрнутый ответ на базе вопросов форума.
Представлен симулятор тимлида, который управляет командой горе-программистов и должен успеть сдать проект в срок. Задача — сдать всё и не выгореть, когда полыхают дедлайны. Всё как в реальном офисе: бесполезные стендапы, куча созвонов с заказчиками, горы тасков и код-ревью. Нужно помогать команде сдать проект и при этом не поехать кукухой.
Ресурс Clone Wars содержит более ста клонов самых полезных сервисов. Например, с помощью этой библиотеки можно разобраться в устройстве самых хайповых программ и попрактиковаться в коде. Есть буквально всё, в том числе и клоны сервисов, ушедших из России: Notion, Spotify, YouTube, TikTok, Discord, Dribble, Dropboх и прочее. Детальный разбор устройства каждого сервиса, кода, архитектуры и функционала, а также советы по его воссозданию. Можно стащить использовать многие решения в своих пет‑проектах.
Яндекс Практикум добавил модули по работе с ИИ во все курсы ИТ-профессий для начинающих
Мы дополнили все курсы из каталогов «Программирование» и «Анализ данных» модулями по работе с ИИ, чтобы наши выпускники не просто «пользовались нейросетями», а превращали их в инструмент профессионального роста — и были востребованы на рынке труда.
Теперь вы сможете:
Разобраться, как устроены нейросети, освоить основы промпт-инжиниринга и научиться подбирать подходящие инструменты.
Использовать AI для быстрого освоения новых технологий и поиска решений.
Применять нейросети для генерации материалов, планирования проектов и оптимизации учебного процесса.
Научиться решать профильные задачи с помощью инструментов искусственного интеллекта.
Со временем, сложность проектов только растет. Какие бы мы изменения в коде не делали, переходили на новые фреймворки, базы, языки или подходы, алгоритмическая сложность (то что в бизнес логике) будет становиться только выше. Технические улучшения максимум могут убрать случайную сложность, когда мы выбрали неверный или не самый эффективный инструмент, но если с точки зрения логики нужно выполнить 30 разных сценариев, мы их запрограммируем в любом случае независимо от выбранных технологий.
Фактически все за что мы боремся когда занимаемся архитектурой проекта, это возможность сделать так, чтобы эта сложность росла как можно медленнее. Потому мы добавляем абстракции (когда без них больно), откладываем принятие ключевых решений и делаем много всякого разного. Естественно все это с учетом требований по производительности, надежности и т.п.
Ниже 5 рекомендаций, по тому, как определить, что выстрелит, а что можно отложить на потом и не сильно париться с кодом.
Грамотное управление состоянием
Говорил, говорю и буду говорить. За всем многообразием принципов и шаблонов, в самой глубине скрывается то как мы работаем с эффектами и процессами (состояния и переходы). Умение видеть это добро в коде и правильно с этим работать это ключ к тому, чтобы система оставалась поддерживаемой и устойчивой к ошибкам на самом нижнем уровне, когда мы на код смотрим как на код.
Изолированная сложность
В любом проекте есть какие-то вычислительные функции, которые работают как черный ящик и ни с чем не связаны. Сюда например, можно отнести все математические функции. Насколько принципиально если внутри грязь и копоть? Практически без разницы, такой техдолг изолирован и не растит общую сложность системы. Его можно воспринимать как библиотечный код, который пришел из зависимостей. Такой код можно переписать в любой момент, когда это станет нужным (например нужно повысить производительность) и с таким кодом отлично справляются LLM.
Приоритеты слоев
Ошибки на уровне формирования моделей и их связей, решают намного больше чем ошибки допущенные при выводе этих данных в api или на фронтенде. Вывод это всегда терминальная стадия, его результаты никак не используются в коде, а вот модели и то как организованы связи, это основа всего, что пронизывает все приложение на самом глубоком уровне. Если тут накосячить, страдать будем в каждой точке сталкивания. Можно сказать что порядок приоритета такой:
модели + структура базы => обработчики (контроллеры, сервисная история) => вывод (сюда же переводы и работа со строками)
Публичные контракты (API)
Все что выставляется наружу, будет иметь серьезные последствия в будущем. Хрен что поменяешь и поправишь. Поэтому на проектирование API нужно уделять внимание. А для этого нужно немного прокачаться, например, в том как делать REST API, знать про открытые и закрытые схемы, про принципы формирования ответов, обработки ошибок и всего такого (а они там есть). Это не хухры мухры, когда речь идет про проектирование каких-то сложных действий, авторизаций и других механизмов.
Отложенные решения
Хорошая архитектура не в том, чтобы заранее все продумать, а в том, чтобы отложить принятие решений до момента, когда у нас есть достаточно информации. Плохие архитектуры чаще всего страдают от преждевременных оптимизаций: усложнили, чтобы “на будущее”, а это будущее не наступило.
- Все, что можно поменять без боли - оставляем простым.- Все, что будет трудно поменять (API, модели, схемы БД, протоколы взаимодействия) - продумываем особенно тщательно.
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-ю сервисами. По мере роста компании, количества команд и сотрудников в отделе нам понадобились единые стандарты в разработке и общий вектор развития. Эти потребности теперь закрывает платформенная команда.
Главная задача платформенной команды — создать фундамент для всей остальной разработки.
Преимущества такого подхода заключаются в том, что появилась единая стратегия технического развития всего отдела, больше возможностей для экономии ресурсов, стандартизации и контроля качества. Кроме того, этот подход способствует эффективному внедрению новых технологий во всех продуктах.
Платформенные команды эффективны, если перед вами стоит вопрос масштабирования технологий внутри компании. Такая команда снижает расходы на разработку, упрощает подбор сотрудников и помогает реализовывать техническую стратегию. Однако такой подход не для всех — он требует определённых масштабов и определённого уровня зрелости организации.
Подробнее о подходе, задачах команды и преодоленных трудностях — в статье на Хабре.
Лайфхак для начинающих разработчиков: уделите время изучению Английского
Да, да, учить не язык программирования, а нативный язык, сначала, или параллельно.
Это нужно чтобы получить преимущество на страте и забрать +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.
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 не знаю что точно надо делать, но решил что буду что-то делать, телеграм канал лишнее таких уже куча а воз и ныне там, очевидно чего-то не хватает, пока можно обсуждать здесь
Авторы из AI Institute, University of Montreal, Princeton University. Статья внушает доверие. Она также подтверждается моими собственными наблюдениями
Ребята говорят о экономии токенов на модельках, 46% меньше потребление ресурса + как следствие ускорение
Суть в том, что модели много рассуждают об известных фактах. Например, если модель попросить решить уравнение с геометрической прогрессией. Она сначала его выведет, а потом будет решать. И так шагов может быть много. У больших моделей есть привычка «думать вслух». Они, когда решают задачу, раскладывают всё по шагам — иногда очень длинно. Это классно для качества, но плохо для скорости и денег: чем больше токенов, тем дороже и медленнее
Пример на прогрессии
Ты просишь модель: «реши уравнение с геометрической прогрессией»
Что она делает?
Сначала начинает выводить саму формулу суммы прогрессии: пишет длинное рассуждение, как она получается.
Потом подставляет числа.
Потом делает вычисления.
И только в конце даёт ответ.
Каждый раз она повторяет эту историю, как будто «заново изобретает велосипед».
Что предлагают авторы статьи
Ребята говорят: зачем каждый раз заново выводить одно и то же? Давайте выделим такие повторяющиеся шаги в маленькие «карточки-подсказки» (они называют их behaviors).
Например, поведение: «Сумма первых n членов геометрической прогрессии = (a₁(1–qⁿ)) / (1–q)».
Теперь, когда модель решает задачу, мы ей сразу даём эту карточку. Она не тратит сотни слов на то, чтобы вывести формулу, а сразу использует её.
Почему это полезно
Экономия ресурсов: в экспериментах до 46% меньше токенов.
Ускорение: модель тратит меньше времени на текст.
Качество не падает, а иногда даже лучше — потому что меньше места для ошибок.
Итог
Классика: модель сама думает длинно, это дорого и долго.
Новый подход: мы даём ей готовые «кирпичики рассуждений» (behaviors), она использует их и отвечает быстрее.
В общем виде: решение = текст задачи + набор подсказок.
Тут можно формулы привести со всякими условными вероятностями. Душнить не буду. И так надо форточку открывать
Приглашаем на вебинар, посвященный вопросам перехода на отечественную Java-среду исполнения. Обсудим, как указы №166 и №250 и приказ Минцифры №21 задали курс на импортозамещение и определили классы ПО для замены.
Поговорим о рисках зарубежных решений, требованиях к безопасности и роли среды исполнения как ключевого слоя ИТ-систем
Кому будет полезен вебинар: • Директорам по информационной безопасности • Техническим директорам • Директорам по ИТ • Руководителям отдела программного обеспечения • Разработчикам информационных систем
Вебинар проведет: Роман Карпов, Директор по стратегии и развитию технологий Axiom JDK, Руководитель ИБ-комитета АРПП "Отечественный софт", Руководитель технического комитета АНО "Открытый код", Советник Министра цифрового развития по вопросам системного ПО, председатель ЦКР по управлению ИТ-инфраструктурой
Всех приветствую! Видел ТГ бота который присылает аварии(инциденты, ДТП) сразу как то их создали на яндекс картах в определенных городах! Попытался сделать такого же, опыт в разработке ботов имеется, но увы я ни как не могу достать из яндекса инфо о ДТП, перерыл все их АПИ, отрисовать на карте слой с ДТП могу, а вот получить данные для обработки ни как вообще! Может кто знает какой то секрет? Буду благодарен любой помощи!
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), которые берут эти сложности на себя
Чем дольше живу, тем сильнее поражаюсь способности людей «заплетать» свои собственные мозги. И, кажется, программисты в этой области вне конкуренции. Уже писал некоторое время назад, как я завел цикл внутри цикла с тем же именем счетчика. Это было пару часов отчаяния, сопровождавшегося размышлениями о том, что фундаментальные законы мира внезапно изменились, а меня забыли поставить об этом в известность. Недавно я повторил этот трюк, правда с некоторыми занятными модификациями. Был у меня в проге цикл по объектам в списке. Там смысл в том, что при некотором условии новый объект добавлялся в конец этого самого списка. Все бы ничего, но в этот момент счетчик объектов инкрементировался. А он то как раз и служил верхней границей цикла… В общем, как легко понять, дело кончилось segmentation fault… Но эту бажину (хотя она даже более заморочная на мой вкус) , я нашел относительно быстро, не успев погрузиться в бездну отчаяния. Кода было немного, поэтому обошлось без смен компилятора и переустановок IDE… В этот раз, можно сказать, повезло. И бездна отчаяния меня миновала. Но тот, кто ищет проблем, обязательно их находит. И что самое удивительное, что я их нахожу всегда в одном месте. Я в-общем то хорошо знаю, что люди еще не придумали ничего хуже конечных автоматов (state machines). И вот уже 35 лет регулярно наступаю на одни и те же грабли… В этот раз мне всего-навсего нужен был один флаг. В задаче Винтика и Шпунтика используется нетривиальный алгоритм, многократно использующий рекурсию. Ну и мне нужен был этот флаг, как индикатор того, что некое событие произошло. А когда происходило другое событие, этот флаг сбрасывался. Стандартная, в-общем, ситуация, но внутренний голос немедленно поднял «красный флаг опасности» и зашептал в голове «Нахлебаешься, Валер, ой, нахлебаешься...» И вот тут бы мне остановиться и подумать, но я, как обычно, решил, что сейчас сделаю, а подумаю потом… Все дело в том, что эти флажки (или состояния конечного автомата) имеют дурное свойство размножаться, куда быстрее чем кролики. За первым флажком немедленно последовал второй — ну просто для того, чтобы обозначить функцию, которая первый флаг установила. А потом третий, чтобы обозначить функцию, которая его сбросила… И мне уже казалось, что вот они разверзающиеся врата ада, но, конечно же, это было еще не так. Ибо настоящий ад наступил, когда программа стала многопоточной. И это еще при том, что у меня есть хорошая привычка обкладывать модификацию всех этих флажков критическими секциями. Даже если не надо. Всегда легче потом убрать и удивиться тому, что все работает, чем сутками докапываться, почему нет. Это уберегло меня от многих проблем, но не уберегло от главной. Сейчас этих флажков в программе 12. И они живут своей собственной жизнью. Я уже не в состоянии отследить кто, где, когда и зачем их модифицирует. Начал думать о том, что надо бы ввести для каждого флажка некую структуру, которая будет содержать ответы на эти вопросы. Но тут уже внутренний голос встал на дыбы, и, как ни странно, в этот раз я его послушал. Вот сижу теперь и думаю над романом (или длинным рассказом) о программисте, который взялся за непосильной сложности алгоритм и постепенно сходит с ума. Хуже того, что он это сам понимает, и ему становится страшно. Но поскольку он программист, то свой мозг он считает конечным автоматом, и пытается его «отлаживать». Таким образом запускается бесконечная цепь рекурсий. И периодически ему приходит в голову мысль, что надо все бросить и написать заново. Но он боится потому что давно уже потерялся и не знает на каком уровне рекурсии он находится… Такой вот юмористический (а может и не юмористический) хоррор с элементами мистики. И легким флером безнадеги из набоковской «Защиты Лужина». Ну вот. Написал пост. Немного отвлекся. Пойду дальше код дебажить…😁
Помогает ли олимпиадное программирование в реальной разработке
Этот и ещё пять тезисов об олимпиадном опыте разобрали с бывшим олимпиадником, Антоном Чаплыгиным, и неолимпиадником, Мишей Усковым. Оба — ведущие инженеры-программисты в Контуре.
В тусовке олимпиадников существует определённая культура превосходства и часто эти ребята воспринимают неолимпиадников как менее квалифицированных программистов
Неолимпиадник: Да. Я ощутил это, когда учился на первых двух курсах универа: перед сессией ребята-олимпиадники говорили, что даже не будут готовиться к экзамену, потому что и так всё знают. 👌 Потом они, конечно, всё заваливали, шли на пересдачу, но гонора до этого момента было много. =) Со временем такие ребята стали проще.
Олимпиадник: Подтверждаю! Например, я пришёл в универ из регионального лицея и у меня были проблемы с неалгоритмическими предметами, например, матанализом. Те, кто уже учил его, считали, что они-то всё знают, а я — нет.
В олимпиадной среде есть соревновательный дух, на нём всё держится. Но считаю, когда попадаешь на учёбу, лучше этот гонор отложить в сторону и с людьми начать нормально общаться.
Олимпиадное программирование бесполезно в реальной разработке. 99% задач в индустрии не требуют сложных алгоритмов
Олимпиадник: Согласен с тезисом, что большая часть задач не требует каких-то алгоритмических подходов, особенно в продуктовых командах. В инфраструктуре этого обычно больше, и когда я сталкиваюсь с алгоритмами, кайфую от этого.
Неолимпиадник: Согласен, что в продуктах алгоритмических задач мало, но они часто критичные. Ты можешь делать 900 простых задач, но без сложных вообще никуда не уедешь. В Контуре есть своя база данных, своя очередь. Мы можем сделать в сервисе много красивых финтифлюшек, но если у нас не будет быстро работать база, мы никому не будем нужны.
Вот ты пользуешься какими-нибудь библиотеками, фреймворками, но при этом не знаешь, что происходит внутри, — это не прикольно. А олимпиадные задачи часто про структуры данных, про Computer Science, и это всё хорошо бы знать.
При этом я считаю, что где-нибудь в промышленной разработке лучший олимпиадник — далеко не всегда лучший программист. Ведь программист — это не только про «У меня есть задача, я превратил её в код», а скорее про «Я знаю, с кем поговорить, что уточнить».
Олимпиадников сложно переучить, они склонны оптимизировать несущественные вещи
Неолимпиадник: У нас в команде были олимпиадники, и когда они брались за задачи, было видно, что им интересно их «покопать», сделать из этого красивое решение, чтобы оно идеально работало. Это всё хорошо, но не всегда такое надо, особенно когда хочется уже быстрее получить результат. =) В этот момент приходилось немного поторопить человека. А потом подсластить ему пилюлю: например, дать прикольную задачу с Computer Science.
Олимпиадник: Считаю, что скорее всё зависит от человека. Бывают люди, которых в принципе трудно переучивать, а бывают те, которым можно объяснить один раз, и они всё поймут. Хорошо, что есть курсы и книжки по чистому коду, в которых ты можешь чему-то научиться и понять, как это применять. Так же, как ты научился писать алгоритмы когда-то.
Алгоритмические задачи на собеседованиях не всегда показывают реальные навыки разработчика
Олимпиадник: Люди во время собеса часто нервничают, из-за этого забывают какие-то элементарные вещи. Но потом, когда приводишь человека в чувство, успокаиваешь, становится понятно, что он всё знает, просто запаниковал тогда и из-за стресса наделал ошибок.
Неолимпиадник: Согласен с этим тезисом, потому что, во-первых человек может запаниковать, во-вторых — ему может попасться задача, с которой он ещё ни разу не сталкивался. Но он точно смог бы решить в спокойной обстановке, когда под рукой поисковик или нейронка. Поэтому считаю, что «валить» кандидата алгоритмами на собеседовании — не самый лучший способ проверить уровень его знаний.
Немного лекций с нашего митапа питонистов в Новосибирске - PythoNSK (https://t.me/python_in_nsk приходите, в ноябре планируем вторую встречу организовать).
Я переписывался с товарищем на тему архитектуры и сформировал более цельное понимание построения ООП-кода :)
Чуть-чуть обо мне: в разработке 12+ лет, сделал 50+ различных приложений и ещё немножко игр, это только для бизнеса, плюс еще мои личные эксперименты и petproject-ы.
Делая все эти приложения я пришел к тому что есть разные подходы к проектированию\моделированию систем, в частности с помощью ООП-кода:
(Условно назову эти типы в игровой терминологии так как разговор был с человеком из геймдева и игры мне тоже близки, кстати, я и программировать то начал чтобы делать игры 😁, итак вот эти подходы: )
1. "Action" - когда ты описываешь объекты как будто смотришь на описываемую систему изнутри (вид из глаз), фокус на взаимодействие объектов между собой в моменте, моделируются в первую очередь сущности и упускаются процессы.
2. "Strategy" - когда ты описываешь объекты как будто смотришь на описываемую систему снаружи (вид сверху), фокус на процессы взаимодействия всех объектов в жизненном цикле приложения, моделируются в первую очередь процессы и упускаются сущности.
3. "God Mode" - когда ты делаешь все что душе угодно (читай как и то и другое, "Action" и "Strategy" в одном флаконе)
И так же я пришел к тому что есть несколько слоев моделирования\проектирования:
(как сказали бы в Теории Систем - есть надсистема, есть система и есть подсистема, а Шрек описал бы это как слои лука, а Осел рассказал бы что это напоминает слоёный торт 😁)
1. Уровень реальности в которой есть человек пользователь, используемый девайс (десктоп, ноутбук, смартфон, и т.п.), сервер с бэкендом; правила их взаимодействия (интерфейсы, протоколы, договоренности); и процессы в которых это взаимодействие происходит (циклы, цепочки событий, потоки данных)
2. Уровень приложения в котором есть сущности бизнес-логики(игровой логики), например Hero, Enemy, Obstacle, Menu, Map, Score; правила их взаимодействия; и процессы в которых происходит взаимодействие
3. Уровень инструментов в котором есть сущности языка программирования такие как примитивы(Int, Long, String, Bool), структуры данных, основные компоненты игрового движка(операционной системы); правила их взаимодействия; и процессы в которых происходит это взаимодействие
(правила взаимодействия могут быть явными и неявными, когда мы описываем объекты классами с методами и функциями, по сути мы уже задаем правила и зависимости объектов, но иногда для удобства мы можем вынести эти правила в отдельные абстракции и интерфейсы, чтобы задать рамки, границы использования однородных классов и абстрагироваться от конкретной реализации, и потом удобно переиспользовать повторяющиеся действия в процессе выполнения)
На каждом слое может использоваться как ООП подход так и ФП, так и нечто смешанное что добавляет удобства.
К чему это все? Наш разговор начался с того что я вбросил мнение что самая чистая архитектура обычно это чистейший ООП-код, и удобство архитектуры зависит как раз от навыка моделирования систем этим ООП-кодом.
Такие дела :)
Я по прежнему считаю что ООП рулит! 😁
А что думаешь ты про ООП, архитектуру и чистый код?
MCP архитектура как развитие ручного подхода в LLM
Когда вы открываете ChatGPT и вставляете туда кучу текста — что реально происходит? Всё складывается в один длинный «бутерброд»: данные, инструкции, системный промпт, даже куски схемы в Markdown. Никакого порядка. Это как если бы у вас в кодовой базе был один файл main.py, где и роуты, и бизнес-логика, и SQL-запросы.
Я хочу описать идею MCP кратко, поскольку в самой доке она не описана. А может быть даже и не закладывалась туда. Но очень похоже, что такая архитектура хорошо работает исходя из более фундаментальных принципов, чем просто разделение
Как это выглядит у ChatGPT
На схеме выше видно:
Есть Line Edit — пользователь копипастит сырые данные.
Есть Плагин — иногда он что-то подмешивает.
Всё это сливается в один большой Склеенный промпт, который уходит в LLM.
Мешанина как она есть
Как это делает MCP?
MCP приходит и говорит: «ребята, давайте хоть модули разнесём».
System Prompt — отдельная часть, где живёт логика «как правильно жить» для модели.
Instruction Layer — патчи и локальные корректировки.
Schema Registry — отдельный каталог, который описывает структуру данных (таблицы, поля, форматы).
Data Adapter — слой, который достаёт данные у провайдера строго по схеме.
Всё это связывает MCP хост, который собирает финальный запрос к LLM, который зачастую представляет собой Lang Chain
Итог: модель получает запрос не как «мусорный мешок», а как структурированный pipeline.
Почему это важно
Прозрачность. Можно отследить, какая часть отвечает за что.
Контроль. Можно менять системный промпт без страха поломать данные.
Расширяемость. Хочешь новый источник данных? Добавь адаптер, а не переписывай всё.
Предсказуемость. Поведение модели становится ближе к детерминированному.
Простая метафора
ChatGPT — это когда у вас «final_final_v3.docx» и все правят его параллельно.
MCP — это когда у вас git с ветками, пайплайнами и CI с CQRS архитектурой (не шутка), читай выше
Я исследовал тему связности и связанности в построении кода и вот к чему пришел:
Не существует плохих\хороших\идеальных связности и связанности кода.
Мне кажется проблема и решение глубже - сколько людей столько и вариантов осмысления и построения "модели", столько вариантов же coupling & cohesion. У каждого что-то свое.
Строить приложение от архитектуры - такое себе. Архитектура для приложения, а не приложение для архитектуры. Тогда архитектура будет основана на реальных задачах а не на поиске идеала.
Самая лучшая архитектура как по мне это когда ты пишешь в ООП стиле, и вот тут как ты умеешь моделировать что-то, такая архитектура у тебя и получится, со всей связностью и связанностью.
Ведь суть всего этого моделирования чтобы "на понятном" объяснить железу что и когда нужно сделать.
Т.е. решение кроется в здравом смысле - описываешь приложение плюс-минус понятными человеку структурами и нужная связность и связанность образуются сами собой как следствие.
Ну и когда я говорю ООП, это не значит что я буду писать абстракцию на каждый чих, влоть до Int, Long и т.п., нет, это значит что я начну с самых больших MyApp { UserClient, ServerClient, DeviceClient } и законтачу их между собой логикой приложения, а там дальше буду создавать абстракции по необходимости, если будет удобно и полезно что-то добавить и переиспользовать то я добавлю и переиспользую (вот кстати хороший критерий - моделировать сущность когда надо что-то передавать между главными абсракциями(надсистемами)).
ООП рулит :)
P.S. И не надо стремиться к идеалу, иначе тут можно скатиться в подмену задач, и начать делать не данное конкретное приложение, а предложенный кем-то идеал архитектуры.
Email и бухгалтерия: почему заголовки писем всё ещё угрожают деньгам компаний
Недавно я писал в одной из новостей про новый стандарт электронной почты — RFC 9788. Тогда это выглядело как чисто техническое обновление: поправили старый костыль, добавили пару параметров, придумали новые заголовки. Но если посмотреть на это глазами бизнеса, особенно глазами топ-менеджмента и бухгалтерии, картина оказывается совсем другой.
Электронная почта — это не только переписка с коллегами или рассылка клиентам. Это канал, через который каждый день проходят платёжки, инвойсы, запросы на переводы. И именно эта часть коммуникаций десятилетиями оставалась в зоне риска, потому что заголовки писем (From, Subject, To) никак не защищались. Мы могли шифровать тело письма, подписывать вложения, использовать все возможные фильтры, но если злоумышленнику хотелось заменить тему на «Срочный перевод контрагенту», он мог это сделать.
В результате бухгалтер получал письмо, где всё выглядело честно: защищённый текст, привычный формат счёта, даже подпись была на месте. А заголовки — самое видимое и доверенное место письма — могли быть переписаны. Именно на этом десятилетиями держались самые простые и самые успешные схемы email-фишинга.
И вот только в 2025 году IETF принял новый стандарт — RFC 9788. Он наконец-то говорит очевидную вещь: защищать нужно не только тело письма, но и заголовки. Теперь все поля копируются внутрь зашифрованной части, наружу выходит только технический минимум, а тема письма может заменяться на […]. Если кто-то попробует подделать заголовок, клиент сразу покажет рассинхрон.
Для разработчиков это очередная спецификация, набор правил и тестов. А для бизнеса это история про деньги и риски. Потому что каждый случай, когда бухгалтер ошибся и отправил платёж по фейковому письму, — это прямой убыток. Каждый подобный инцидент — это ещё и риск для репутации: в новостях упоминают не мошенников, а именно ту компанию, которая «повелась».
Да, внедрение будет постепенным: сначала open source-клиенты и энтузиасты, потом корпоративные почтовики, потом массовый рынок. Но уже сейчас очевидно, что компании, которые раньше внедрят RFC 9788, снизят риски быстрее. Это история не про «технологическую моду», а про то, сколько денег вы теряете или экономите.
Я уверен, что лет через пять защищённые заголовки будут восприниматься так же естественно, как сегодня HTTPS на сайтах. И точно так же, как сейчас мы удивляемся сайтам без https, пользователи будут удивляться письмам, где можно переписать тему или отправителя. Вопрос только в том, вы хотите оказаться в числе тех, кто внедрил это вовремя, или в числе тех, чью бухгалтерию упомянут в очередной криминальной хронике.
RFC 9828: стандарт, который, странным образом, опоздал лет на двадцать
JPEG 2000, появившийся ещё в начале нулевых, давно используется в задачах, где требуется высокое качество изображения, а RTP как транспорт для данных реального времени уже более двадцати лет обеспечивает надёжность. Однако, и это удивительно, всё это время отсутствовал формализованный стандарт, позволяющий передавать JPEG 2000 с минимальной задержкой, по кускам кадра, не дожидаясь его полной готовности, — и лишь в 2025 году он был наконец принят. Можно только гадать, почему в мире, где запускают ракеты в космос по подписке, инженеры продолжали смиренно ждать, пока кадр целиком упадёт в буфер.
Теперь же, с появлением RFC 9828, ситуация меняется: простое на первый взгляд решение — передавать кадр частями, а не целиком, — становится официальной нормой. Как только кодер начинает производить данные, пакеты уже могут быть отправлены в сеть, а приёмник, не дожидаясь окончания всего кадра, начинает сборку изображения. И именно это означает, что впервые JPEG 2000 становится пригодным для таких сценариев, где маркетинговый термин «low latency» оборачивается критическим требованием: телевещание в прямом эфире, дистанционная хирургия или работа со сверхкачественным изображением в реальном времени.
Вместо прежнего порядка «сначала кадр, затем поток» появляется обратный — «сначала поток, затем кадр». Благодаря этому сеть получает ту самую гибкость, о которой раньше говорили как о недостижимой: лишние уровни разрешения и качества можно отбрасывать на лету, даже не вскрывая содержимое. Приёмник, в свою очередь, обретает resync-точки, благодаря которым потеря пары пакетов больше не превращается в катастрофу, а разработчики, наконец, могут избавиться от бесконечных костылей, изобретённых в обход RFC 5371.
Выгоды для бизнеса очевидны, хотя каждый сектор формулирует их по-своему. В телевидении по IP режиссёр теперь видит кадр практически сразу, а не спустя полсекунды, и значит — работа в реальном времени перестаёт быть фикцией. В медицине появляется возможность стримить эндоскопию или МРТ с качеством вплоть до lossless и при этом не терять драгоценные секунды, от которых зависит исход операции. Кинопроизводство перестаёт таскать гигабайты по дискам, потому что мастер-кадры наконец-то могут пересылаться по сети. Даже государственные сервисы, включая суды и видеоконференции, приобретают шанс выглядеть не как мем из 2008 года, а как инструмент XXI века.
Да, пока это лишь бумага. Но, как обычно бывает: сначала RFC, затем — первые SDK и FPGA-решения, а чуть позже — перепакованные в отраслевые документы SMPTE и ITU стандарты. В горизонте двух-трёх лет мы увидим первые реальные внедрения в телевидении и медицине, в горизонте пяти — широкое распространение. А дальше, возможно, даже lossless-видеозвонки без лагов перестанут казаться фантастикой.
RFC 9828 — это не просто ещё один формат. Это признание индустрии в том, что ждать конца кадра всё это время было, мягко говоря, глупо.
🤖 Запустили AI-помощника Клаудию — она доступна в вашем личном кабинете. Клаудия поможет создать ВМ, уточнит задачу и подберет конфигурацию, подскажет команды в консоли. А еще настроит виджеты, алерты и нотификации для контроля ВМ, поможет найти нужное в документации и выступит как co-pilot. Попробуйте бесплатно — новым пользователям дадим 4 000 рублей на облачные ресурсы.
🖥️ В Evolution Foundation Modelsоткрыли доступ к новым open source моделям, в том числе к OpenAI 120b, Qwen-3, GigaChat, GLM-4.5 и другим. Всего доступно 20+ LLM, ранжировщиков и эмбеддеров, а до 31 октября вы можете бесплатно потестировать их на своих проектах.
Участвовали в крупных мероприятиях:
Провели митап Cloud․ru Tech Lab: AI&ML, где рассказали, как автоматизировали пользовательские сценарии с помощью AI-агента, разобрали устройство агентов, RAG и Ragas. А еще слушатели могли вживую пообщаться с экспертами, «прожарить» свое резюме и посетить демозону AI-решений на базе Cloud․ru Evolution.
Организовали конференцию GoCloud Tech 2025 о создании решений на базе AI и облаков. Обсудили кейсы внедрения AI&ML, тренды в создании облачной инфраструктуры, актуальные практики для работы с данными в облаке.
Во второй раз приняли участие в крупнейшей AI-выставке в мире — World Artificial Intelligence Conference в Шанхае 🇨🇳 На нашем стенде мы показали платформу Cloud․ru Advanced, провели встречи с Geely, Tencent, Baidu, IFlytek, GAC, TikTok, Alibaba, Li Auto и другими зарубежными компаниями.
🧠 Запустили бесплатный курс про создание ML-моделей и их внедрение в бизнес. Будет полезно менеджерам продуктов и проектов, DS-, backend- и frontend-разработчикам, продуктовым дизайнерам. Можно учиться в комфортном темпе, а в конце дадим именной сертификат.
✨ Предлагаем бесплатно протестировать сервисы Evolution Data Platform — новой платформы для полного цикла работ с данными:
Evolution Managed BI для визуализации и анализа данных в облаке, в стадии public preview;
Evolution Managed Airflow поможет управлять рабочими процессами. Находится в стадии private preview — напишите своему аккаунт-менеджеру, чтобы начать тестирование.
Запустили в публичное превью и другие сервисы Evolution Data Platform:
Обсудили с Павлом Наумовым, первым вице-президентом Газпромбанка, как меняется клиентский путь и что такое «человеколюбие» в цифровых продуктах. Смотрите на удобной площадке: VK Видео, YouTube или Rutube.
💳 Упростили регистрацию в реферальной программе: теперь подать заявку можно в несколько кликов, а на каждом этапе вы можете получить помощь менеджера. Присоединяйтесь к программе до 30 сентября, рекомендуйте сервисы Cloud.ru, получайте 20% от суммы их чеков в первый год и 15% — в последующие.
