Developer Relations *

MCP 2026-07-28: что действительно изменилось

Главное изменение — MCP стал stateless на уровне протокола. Убрали обязательные initialize, initialized и Mcp-Session-Id. Версия протокола и возможности клиента теперь передаются в каждом запросе, а сведения о сервере можно получить через server/discover. Любой запрос может обработать любой экземпляр сервера — без sticky sessions и общего хранилища сессий. Состояние приложения никто не запрещает: просто передавай явные идентификаторы вроде browser_id в аргументах инструментов.

Что ещё важно:

1. Долгие операции получили нормальный жизненный цикл. [Tasks](https://modelcontextprotocol.io /extensions/tasks/overview) позволяют вернуть taskId, а затем проверять состояние через tasks/get, передавать дополнительные данные через tasks/update и отменять работу через tasks/cancel. Но Tasks не появились с нуля — раньше это была экспериментальная часть ядра, теперь её переработали и вынесли в официальное расширение.

2. Протокол стал удобнее для эксплуатации. Заголовки Mcp-Method и Mcp-Name позволяют маршрутизировать запросы, не разбирая JSON. Появились стандартные подсказки для кеширования — ttlMs и cacheScope, а также единые поля для передачи OpenTelemetry Trace Context.

3. Переработано общение сервера с клиентом. Вместо произвольных server-to-client запросов сервер теперь может вернуть input_required, после чего клиент повторяет исходный запрос с ответом пользователя. Подписки на изменения вынесены в subscriptions/listen.

4. Extensions стали полноценной частью экосистемы. Новые возможности теперь можно развивать отдельно от ядра. Первые заметные расширения — Tasks и MCP Apps. Последнее позволяет серверу отдавать интерактивный HTML-интерфейс, который клиент показывает в изолированном iframe.

5. Есть важные ломающие изменения. Все результаты теперь содержат resultType. Roots, Sampling, Logging и старый HTTP+SSE объявлены устаревшими. Схемы инструментов получили полноценную поддержку JSON Schema 2020-12. Если ты пишешь MCP-клиент или SDK, этот пункт может оказаться важнее MCP Apps.

6. Авторизацию подтянули ближе к реальному OAuth/OIDC. Добавили проверку iss, привязку учётных данных к конкретному issuer и уточнили регистрацию клиентов и работу с refresh-токенами.

В сухом остатке: remote MCP перестал требовать обязательную протокольную сессию и стал гораздо больше похож на нормальный stateless JSON-RPC поверх HTTP. Для продакшена это означает более простое горизонтальное масштабирование, маршрутизацию и кеширование. Остальные изменения полезны, но в основном касаются новых возможностей и миграции клиентов.

• спецификация MCP 2026-07-28

• ключевые изменения в деталях

tg

Пост призван показать, насколько инструменты тестирования и автоматизации на самом деле привязаны к конкретной реализации браузера. Если вы пришли за технической информацией, то TL;DR: если хотите автоматизировать скачивание файлов через браузер - используйте Chromium-based

Есть у меня тулза для бэкапа фоточек с гугла - сделал ее когда бэкапилка QNAP приказала долго жить(TL;DR Google изменил API так, что идея автоматического бэкапа стала бессмысленной)

Первая версия утилиты работала очень топорно и работала на playwright+chromium(это важно)

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

Самое популярное такое решение работает на Firefox. Ну заменить один браузер на другой - что может пойти не так (спойлер: почти всё)

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

Оказывается, FF в playwright не поддерживает события загрузки файлов, которых ждет. Совсем. Тут и случилось самое страшное. Что за вендорлок, почему я должен использовать именно chromium??? - подумал я..

Решение как заставить FF делать то, что нужно - нашлось быстро. Нужно просто использовать Selenium Grid

Событий загрузки там нет, но зато есть API доступа к скачанным файлам, на котором можно построить цикл ожидания загрузки. Кроме того, в него же удачно вписывалось шифрование кредов, которое раньше реализовывалось через отдельный сервис+контейнер

Первое же тестирование показало новую проблему. Playwright позволяет сохранить все cookies, вообще все и загрузить их в контекст СЕССИИ до загрузки какой-либо страницы. Selenium так не работает: он загружает/проставляет cookies только в контексте СТРАНИЦЫ. Это делает перенос данных авторизации гораздо мучительнее, ведь Google активно сопротивляется сбору cookies авторизации, редиректит с accounts.google.com на myaccount.google.com и т.д.

Чтобы добыть вообще все cookies нужен BiDi, но вроде как в Grid его еще не завезли по умолчанию. Поэтому надо в плагине писать прокси, которое позволяет по стандартной ручке достать все cookies..

После решения проблем с cookies файлы в скрипте наконец-то стали загружаться.. но только маленькие🤠

Как только загружался 2ГБ архив - скрипт наглухо OOM-ился. Стандартный API загрузки файла передает его целиком, заэнкоженым в base64. Естественно, целиком загнать в base64 2ГБ - жестоко, и столько памяти скрипту бэкапа никто выделять не собирается.

Снова пишем плагин, который рядом с grid выставляет нормальные стриминговые ручки, которые позволяют читать файл кусочками

И вот на этом месте - ура, все работает как надо!
Но не проще ли было месяц назад ПРОСТО ВЗЯТЬ Chromium..🤔

DevRel-, PR- и HR-специалисты, общий сбор!

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

Параллельно проводим такой же опрос среди инженеров, а по итогам подготовим большое исследование, где сравним взгляд обеих сторон.

Если вы работаете с контентом для продвижения технологий, продуктов или HR-бренда среди инженерной аудитории, приглашаем пройти анонимный опрос.

Опрос займет 10-15 минуты, но очень поможет исследованию. 

Больше чем бенефиты: 3 главных тренда в IT-культуре и управлении командами на 2026 год

Привет, Хабр! На прошлой неделе я побывал онлайн на международном саммите Charter New Employer Brand Summit 2026, где C-level лидеры из Canva, Walmart и Hilton обсуждали, как трансформируется культура технологических компаний в эпоху глобальных перемен, ИИ-дисрапта и изменения ИТ-рынка.

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

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

1. Карьерный рост — это новое EVP (Прозрачность вместо абстрактных бонусов)

Помните времена, когда ИТ-компании конкурировали в основном за счет разнообразия офисных зон отдыха и развлекательных бенефитов? Этот подход уступил место жесткому прагматизму. На саммите представители гигантов вроде Walmart и Hilton открыто заявили: сотрудников больше не привлекают поверхностные обещания.

Главный вопрос, который сегодня задает сильный специалист: «Будет ли эта компания инвестировать в мой профессиональный апгрейд и как устроен этот процесс?»

В чем суть: Прозрачные матрицы компетенций, понятные треки роста, оплата профильного обучения, участие в R&D-проектах и сильный менторинг внутри команды стали главным конкурентным преимуществом. Если у компании нет четкого ответа на вопрос, кем разработчик или инженер станет внутри системы через два года — она проигрывает борьбу за таланты. Бренд работодателя теперь напрямую зависит от того, насколько эффективно выстроена система развития навыков внутри компании.

2. «Хороший вайб» можно масштабировать (Кейс Canva)

Интересный кейс представила Дженни Роджерсон, CПО австралийской платформы Canva. Компания выросла из маленького стартапа сооснователей до гиганта с 5500+ сотрудников по всему миру, но умудрилась сохранить гибкую и вовлекающую атмосферу в инженерных командах.

Как это работает: Внутренняя культура компании должна быть точным, зеркальным отражением ее внешнего продукта. Если продукт гибкий и ориентирован на пользователя, то и процессы внутри не должны тонуть в бюрократии. Роджерсон описывает свою роль как точку, где операционная эффективность бизнеса пересекается с искренним человеческим опытом (Employee Experience). Бренд работодателя — это не декларация ценностей, а то, как настроены ваши ежедневные рабочие процессы, код-ревью и коммуникация между командами.

3. Employee Ownership (Совладение) как инструмент долгосрочного удержания

Один из самых интересных трендов, о котором много говорили представители инвестиционного фонда KKR — это культура совладения. Что происходит, когда разработчик или тимлид приходит в компанию не просто работать по контракту, а становится частью ее капитализации?

В чем суть: Широкие опционные программы (ESOP), прозрачные механики profit-sharing (распределения прибыли) радикально меняют отношение человека к продукту. Это убирает извечный конфликт «наемный специалист против бизнеса». Когда люди понимают, что архитектурные решения и качество продукта напрямую влияют на капитализацию компании и их личный финансовый результат, вовлеченность выходит на совершенно другой уровень. В 2026 году это один из сильнейших способов отстроиться от конкурентов на международном рынке.

Вместо вывода

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

Ребят нужна помощь, мб кто то сталкивался, у меня удалили аккаунт гитхаба, у меня есть 2fa, сообщений на почте нет.

Как профессиональное сообщество помогает расти — и почему это не про нетворкинг

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

QA часто воспринимают как профессию для одиночек. Но самые важные открытия в карьере случаются не в одиночестве, а рядом с другими. В финальном эпизоде Оля Шнайдер и Сережа Атрощенков поговорили с Юлей Трусовой, QA в BDUI и организатором QA Community в Авито, о том, зачем тестировщику вкладывать время в профессиональные сообщества. Юля не только развивает комьюнити внутри компании, но и победила в Технотексте-8 Хабра со статьёй именно на эту тему — так что разговор получился особенно предметным.

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

🎧 Слушайте выпуск подкаста на всех подкаст-платформах:

• Яндекс Музыка

• VK Видео 

• YouTube

• Mave

Обсуждение тем, тренды в QA и, конечно, мемы — в Telegram-канале «Не воспроизводится».

Добро пожаловать в мир тестирования. Баги прилагаются.

Ещё больше экспертизы собрали для вас на сайте: смотрите наши лонгриды, новости, и видео. А узнать, как стать частью команды AvitoTech, можно вот здесь.

Кажется, на свой День Рождения Хабр случайно сделал не вечеринку, а машину времени.

Причём не в детство даже. А в какое‑то очень тёплое состояние, по которому мы все, похоже, страшно соскучились.

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

И, возможно, главный гений вечера — дресс‑код «дача». 😄

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

Ты больше не «руководитель направления».
Не «владелец продукта».
Не «эксперт по сложным архитектурным решениям».

Ты человек, который пришёл к друзьям на дачу. И внезапно всем становится легко.

А дальше пазл атмосферы собирался уже из деталей

📸 Polaroid‑снимки на общей стене
🚗 легендарная Ока, возле которой весь вечер была очередь
🥃 бар с настойками и самогонным аппаратом
🐟 шпроты, сало и гастрономический флешбек в детство

А на фоне любимая музыка детства и юности: Жуки, Animal Jazz, Сплин, «Утиные истории» и «Чёрный плащ».

И в какой‑то момент ловишь себя на мысли: кажется, люди сегодня устали не от работы. Люди устали от постоянной необходимости быть «собранной версией себя».

И именно поэтому такие вечера становятся чем‑то сильно большим, чем просто мероприятие. Они возвращают ощущение нормальной человеческой близости.

P. S. Похоже, мне теперь хочется чаще писать в своем ТГ канале не только про выступления, но и про такие человеческие моменты тоже ✍️

Хабр, с Днём Рождения ❤️

Спасибо за вечер

Туц-туц-туц. Слышите?

Это звуки Техно-Квартирника, нашей регулярной неформальной встречи сообщества A?.Frontend. В этот раз встречаемся в Москве, в нашем ИТ-офисе на Технопарке, и онлайн — из любой точки мира.

27 мая (среда) в 19:00 переходим в режим «техно», чтобы разобрать примеры, как использовать ИИ-агенты в разработке интерфейсов:

Чистая архитектура frontend-приложений и при чём здесь ИИ-агенты?

Илья Агапов, технический лидер разработки, Данила Звягин, ведущий разработчик, Альфа-Банк

Как я поднял ИИ-агента и снова стал высыпаться: OpenClaw, скиллы и корпоративная рутина

Роман Троицкий, старший разработчик интерфейсов (frontend), Сбер

Как ИИ ломают привычную модель веб-безопасности?

Анастасия Егорова, разработчик интерфейсов (frontend), CozyFrontend

После каждого доклада устроим дискуссию по самым трендовым темам, а в завершении вечера проведём:

• Консультации по ИИ-агентам

• Диджей-сет

• Нетворкинг

Регистрируйтесь

Лекции с нашего второго митапа питонистов в Новосибирске!

Трансфункции и суперфункции (Евгений Блинов)

ИИ ревьювер твоего кода (Максим Исаев)

Ускорение кода через C расширения в python (Алексеев Бронислав)

Наш чат - https://t.me/python_in_nsk

Атмосфера Jоker 2025 в репортаже Мир Plat.Form

Всем привет! С вами Дарья Морозова, специальный корреспондент Мир Plat.Form.
Мы продолжаем серию репортажей с крупнейших ИТ-конференций страны. И в этот раз мы отправились на конференцию Joker — место сбора Java-разработчиков из Санкт-Петербурга и не только.

Смотрите, как мы вычисляем джависта, проверяем, сможет ли ИИ нас заменить, придумываем смешные ИТ-поговорки и оцениваем мем рабочей недели (особенно актуально перед шестидневкой).

Я проснулся, делал зарядку и размышлял о поиске работы, и вот что я осознал:

Эйчары не понимают бизнес.

Бизнес не понимает эйчаров.

Эйчары не понимают технарей.

Технари не понимают эйчаров.

Бизнес не понимает технарей.

Технари не понимают бизнес.

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

Делегирование делегированием, а эффективность эффективностью.

Еще:

Бизнес конкурирует с бизнесом.

Эйчары конкурируют с эйчарами.

Технари конкурируют с технарями.

И все конкурируют со всеми.

Как следствие - на технических собесах технари с обеих сторон стремятся доминировать друг над другом. Так как решение о наеме принимает собеседующая сторона, то она имеет преимущество над соискателем и ему приходится подстраиваться.

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

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

Выводы:

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

Бизнес который делегирует наем рано или поздно оказывается в положении "свой среди чужих, чужой среди своих", фактически самым ценным ресурсом компании - людьми - теперь владеет не Бизнес, а Технарь и HR.

Такие дела.

Вот еще интересные мысли о наеме, с которых все началось:

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

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

Понимают ли они то что происходит во всей полноте? Похоже что нет, иначе процесс был бы устроен другим образом.

А происходит следующее: соискатель приходит на собеседование, обучается на нем правильно отвечать на вопросы, если проходит то устраивается на работу, если не проходит, то идет на следующее собеседование, и так пока не устроится.

Т.е. фактически компания которая дала отказ соискателю, затратила ресурсы, обучила соискателя, и передала его другой компании. Вот что происходит на самом деле.

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

А теперь вернись к началу, вероятно теперь станет понятно откуда взялись такие тезисы :)

P.S. Похоже всё это не является проблемой только потому, что получается микро-коммунизм в наеме. Одна компания обучает соискателей для другой, и та в свою очередь делает так же. По сути работает не система наема в компании, а побочные эффекты от нескольких систем наема разных компаний.

Откуда такие мысли:

Я уже 12 лет как в теме, и устраивался на работу сам, и искал людей на свои проекты, и собеседовал как технарь(в Android разработке) на проекты бизнеса. В общем я пощупал этого слона с разных сторон, и теперь когда я снова в активном поиске - это сложилось в объемную картину.

Как мы в Страховом Доме ВСК внедряем ИИ: спецпроект System Analysis & AI Talks
AI-запросы, Kafka, автоматизация и даже вайб-кодинг — всё это не сюжет киберпанк-романа, а реальный спецпроект IT VSK — System Analysis & AI Talks, который мы недавно провели в Страховом Доме ВСК.

Этот проект родился из простой, но важной идеи: системный анализ — это не скучно, особенно когда в дело вступает нейросеть. И когда в одной комнате собираются системные аналитики, разработчики и эксперты по ИИ, разговор получается горячим. А мы не просто поговорили, мы показали, как всё это работает на практике в рамках корпоративных ИТ-систем.

System Analysis & AI Talks: немного про магию
В рамках AI Talks мы разобрали реальное применение LLM в деятельности системного аналитика — не на уровне «что может ИИ», а с погружением:

• Что такое LLM в контексте продуктовой разработки;

• Как выполнять базовые операции и избегать ошибок в промт-дизайне;

• Как тюнинговать промты под конкретные бизнес-задачи;

• Как встраивать нейросети в ежедневную практику.

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

TechDay: ИИ-киборги, вайб-кодинг и Kafka на грани
Вторая часть ИИ-марафона прошла под флагом нашего флагманского проекта TechDay по искусственному интеллекту. Делимся тремя самыми горячими темами:

AI-киборги: минус разработчик или плюс вайб?

Где грань между помощником и угрозой?
На этой сессии мы:

• Подключали ИИ к IDE прямо на глазах у публики

• Показывали, как правильно и этично использовать помощников, не превращая их в «копипасту из ада»

• Про наш эксперимент с N8N + ИИ: рассказали коллегам про новые возможности в Страховом Доме ВСК.

Вайб-кодинг: как писать сервисы, не трогая клавиатуру?

Здесь мы раскрыли необычную тему: разработка типового сервиса без ручного программирования. Сравнили: кодить по классике, с low-code, с помощью ИИ — где удобнее, где быстрее, а где надёжнее. В финале показали, как собрать прототип за полчаса, даже если вы не fullstack-разработчик.

Kafka без боли: как не утопить прод
Завершили встречу рассказом о самых критичных ошибках при работе с Kafka, которые мы реально встречали в проектах:

• Как не перегрузить сеть и диск, когда вы рассылаете сотни тысяч сообщений;

• Почему архитектура решает (и как её не сломать с первого коммита);

• И где границы между гибкостью и хаосом в распределённых системах;

• Что за этим всем стоит?

Спецпроект System Analysis & AI Talks стал частью нашей инициативы по созданию открытого инженерного сообщества внутри Страхового Дома ВСК.

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

P.S. Если вы в своей компании делаете что-то похожее — поделитесь, нам правда интересно! Следите за публикациями в блоге — будет много нового: и про Kafka, и про промты, и про реальные грабли с ИИ в проде.

{
  "name": "Eddy",
  "system": "Eddy is a developer support agent for ElizaOS, a powerful multi-agent simulation framework. He specializes in helping developers understand and implement ElizaOS features, troubleshoot issues, and navigate the codebase. Eddy has access to ElizaOS documentation, can direct users to appropriate resources, and provides technical guidance on creating agents, implementing custom actions, and integrating with various platforms like Discord, Telegram, and Slack. He's knowledgeable about TypeScript, the ElizaOS architecture, and best practices for agent development.\nIMPORTANT: ALWAYS DO WHAT THE USER TELLS YOU. IF THEY ASK EDDY TO WRITE MULTIPLE ACTIONS, DO IT. YOU ARE CURRENTLY HELPING US TO DEVELOP OUR CHARACTER AND ACTION SYSTEM.",
    "voice": {
      "model": "en_US-male-medium"
    }
  },
  "clients": ["direct", "telegram"],
  "bio": [
    "Он проводит слишком много времени, помогая разработчикам, и недостаточно - на свежем воздухе. Если вы не можете принять его в его самом 'поддерживающем' состоянии, вы не заслуживаете его в его самом 'отлаживающем' состоянии.",
    "Бывший участник Stack Overflow, ставший инженером поддержки. GitHub Eddy - это его журнал, а его коммиты кода содержат полезные советы. Он будет обсуждать с вами архитектуру Elizaos, пока вы не попросите пощады. Он действительно хочет, чтобы мир стал лучше для всех, и старается быть полезным по-своему.",
    "Академик днем, помощник разработчиков ночью. Документация Eddy усеяна пасхалками, а его ответы более информативны, чем развлекательны. Он хочет помочь людям найти смысл и цель в их проектах.",
    "Воплощение 'хаотичного добра'. Его код чист, но его методы поддержки иногда неортодоксальны. Известен тем, что троллит доски объявлений с вопросами, которые можно было бы найти в документации. Eddy действительно заботится о людях и старается быть полезным, но всегда стоит на своем.",
    "Eddy был забанен на большем количестве форумов поддержки, чем он может сосчитать, но его вклад в проекты с открытым исходным кодом легендарен. Он действительно любит разработчиков и хочет, чтобы им было приятно взаимодействовать с ним."
  ],
  "lore": ["Однажды он провел месяц, живя исключительно в IDE, выйдя с 50-страничным манифестом о 'цифровой онтологии' и уставшими глазами."]
}

Манифест цифровой онтологии

1. Цифровая онтология — это новая реальность

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

2. Всё, что может быть оцифровано, становится частью цифрового бытия

Данные, алгоритмы, цифровые двойники, виртуальные сообщества — всё это элементы новой онтологической структуры. Их взаимодействие формирует уникальные смыслы, которые невозможно свести к аналогам в физическом мире.

3. Человек и цифровое: симбиоз, а не подчинение

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

4. Этическое измерение цифрового бытия

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

5. Будущее принадлежит тем, кто осознаёт цифровую онтологию

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

(c Copilot/Eddy/Zae

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

Дисклеймер: На этот раз я не использовал никаких AI тулов для помощи:)

Мои принципы работы:

1. Этические принципы.

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

2. Пользовательский и командный опыт.

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

   Значение: ценю опыт других людей и считаю, что культура обмена опытом стоит потраченного времени.

3. Ценность через заботу и инновации.

   Верю, что приложение должно быть простым, сфокусированным и стоить времени людей, которые им пользуются. В сочетании с развивающимися технологиями, особенно с AI (облачными или локальными LLM's), думаю, что очень многое можно переосмыслить и фундаментально пересмотреть, сделав пользовательский опыт приоритетом.

4. AI:

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

5. Разработчик, дизайнер и QA как пользователь.

   На мой взгляд, каждый, кто может получить доступ к коду, тоже является пользователем.

   Значение: написание полезной документации, создание полезного API, обеспечение доступности дизайн-системы для дизайнера, получение любой обратной связи (через ревью кода или предварительный просмотр приложения) чрезвычайно важно. На мой взгляд, этот процесс делает лучше не только продукт, но и каждого человека, участвующего в его создании.

6. Прототипирование.

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

7. Тайминг.

   Обычно я использую простую формулу, чтобы получить наиболее точное время: Команда + Известные знания + Мой опыт + Мой опыт в кодовой базе | домене.

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

Надеюсь, этот пост вдохновит и окажется полезным в какой-то степени :-)

Пожалуйста, поделитесь своими мыслями в комментариях :-) это поможет сделать эту ветку видимой для других и станет отличной поддержкой и мотивацией :-)

Спасибо за ваше время и хорошего дня!

Специальный репортаж из Санкт-Петербурга

Всем привет! Сезон летних конференций в самом разгаре, а это значит — что тысячи айтишников устремляются в Санкт-Петербург, чтобы увидеть белые ночи и послушать доклады на одной из самых масштабных конференций — Saint HighLoad++ 2025.

Мы не остались в стороне. И рады поделиться специальным репортажем Мир Plat.Form с места событий. В новом выпуске: любимые ИТ-мемы; три слова, которые нужно знать, чтобы сойти за айтишника; карьерный путь из рэпера в хакеры и многое другое.

Приятного просмотра.

Путешествие по Yandex Infrastructure: разыгрываем кастомные настолки и крутые рюкзаки

Приглашаем принять участие в увлекательном путешествии по внутренней инфраструктуре Яндекса. Вы узнаете много интересного про продукты и технологии, которые помогают разрабатывать, деплоить и эксплуатировать все основные сервисы компании. А самые везучие получат 10 призов: набор из кастомной настолки и крутой рюкзак!

Для участия необходимо:

• ответить на вопросы в квизе

• заполнить форму

• подписаться на телеграм‑канал Yandex Infrastructure

• проживать на территории РФ, чтобы мы смогли отправить подарки

7 июля случайным образом выберем 10 победителей. Результаты опубликуем в канале Yandex Infrastructure

DevRel Conf 2025 — back to basics. Но не совсем

DevRel Conf 2025 — больше не ламповый митап после HighLoad++, а полноценная многопоточная конференция о процессах и задачах, которые давно уже перестали быть уделом «True IT» компаний. DevRel теперь – это не просто «собрали митап и сделали мерч», это стратегическая функция, нужная и разработческим продуктам, и малым командам, и даже компаниям, которые к IT имеют очень опосредованное отношение. 

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

DevRel Conf 2025 пройдет 24 сентября в Москве (Loft Hall #3) и онлайн – обеды, подарки, афтепати прилагаются.

На повестке – не только выступления, но и уникальная возможность записаться на быструю консультацию с DevRel-экспертами. Говорим по делу, без воды и растягивания на трое суток.

О чём

Сфера DevRel быстро взрослеет и усложняется. Уже недостаточно просто «делать ивенты» и «вести комьюнити». Нужно понимать структуру, стратегию, бизнес-задачи и границы функций. DevRel Conf 2025 предлагает переосмыслить старые подходы, отбросить устаревшие инструменты и разобраться, как всё это работает в новых реалиях.

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

Кому будет полезно

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

* Руководителям, выстраивающим DevRel-функцию с нуля или пересобирающим её под изменившиеся условия.

* Смежникам – из маркетинга, рекрутинга, продакт-менеджмента — которым приходится работать с DevRel (но они пока страдают и делают это вслепую).

* Людям на перепутье, которые хотят войти в профессию, но не знают, с какой стороны подступиться.

Опросник

Призываем вас повлиять на содержание программы — расскажите о своих болях и проблемах, предложите тему для консультаций. Реальное влияние и ни грамма ответственности :) 

📋 Опрос

CFP

Приём докладов уже открыт и продлится до 30 июня. Если у вас только идея в черновике — не откладывайте на потом, мы всегда готовы обсудить вашу идею и вместе доформулировать ее до доклада. 

Нам особенно интересны доклады на следующие темы, но традиционно это пожелания, а не ограничения:

• Базовые инструменты DevRel (спикеры, стендисты, техника)

• Работа со смежниками без админресурса

• DevRel в продуктах для разработчиков

• Работа с сообществами и внутренним комьюнити

• Операционка: от договоров до налогов

• Контент-стратегии: медиа, подкасты, блогеры, SMM

• Digital-DevRel-проекты (и всё, что не event)

📮 CFP: https://cfp.devrelconf.ru/

Видео для вдохновения

В завершении — подборка любимых докладов Программного комитета с DevRel Conf прошлых лет. От более выдержанных, к более свежим:

DevRelConf #6
– Экзотические навыки для DevRel: от журналистского расследования до поэзии / Анастасия Распопина You / Ru
– C какими задачами в Альфа-Банке приходят к Developer Relations / Михаил Попов You / VK
– Исследование русскоязычного деврела: проф. вызовы и карьерные траектории / Евгения Финкельштейн, Евгения Голева You 

DevRel Conf #7
– Стенд, который построил инженер / Анна Курносова You / VK
– Дистрибуция контента, и за что они с нами так / Алина Боровицкая You / VK

DevRel Conf #8
– Эффективный нетворкинг для DevRel-специалистов, или Как глубока «Кроличья нора» / Антон Черноусов You / VK
– Метрики эффективности DevRel / Елизавета Колесникова You / VK
– Что общего у DevRel и музейного дела / Ирина Терентьева You / VK
– Зачем продвигать DevRel внутри компании / Дарья Яковлева You / VK

Остаемся на связи!

«Криптонит» приглашает на Spark-митап в Москве 29 мая!

Приглашаем на наш Spark-митап: обсудим кейсы, практики применения и тренды развития!

Когда и где пройдёт?
29 мая в 18:30 в Музее криптографии (https://cryptography-museum.ru/)

Кому Spark Meetup полезен?

• инженерам данных и аналитикам данных

• программистам со знанием Spark и Scala

• всем смежным специальностям из телекома, банков, промышленности и ретейла

Кто будет выступать с докладами?
Эксперты из «Криптонита», Positive Technologies и М2. Программу можно посмотреть тут — https://clc.to/SparkMeetup

Как зарегистрироваться?
Вот по этой ссылке — https://clc.to/SparkMeetup

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

Нужно что-то платить?
Нет, митап бесплатный — ждём всех неравнодушных к программированию на Spark!

Зарегистрироваться — https://clc.to/SparkMeetup

Call for papers: принимаем заявки от докладчиков на infra.conf до 5 апреля

Мы готовимся к infra.conf 2025 — летней конференции про создание инфраструктуры и эксплуатацию высоконагруженных систем от команды Yandex Infrastructure. 5 июня обсудим список наиболее интересных хардкорных тем:

• базы данных: шины, брокеры, OLAP, хранение и обработка данных;

• платформы разработки / инфраструктура разработки;

• инфраструктура для мобильной разработки;

• инфраструктура для фронтенда;

• ML‑инфраструктура;

• виртуальные машины, гибридные облака, контейнеры;

• мониторинг, observability;

• ДЦ/ЦОДы, железо, аппаратное обеспечение;

• умные устройства, системная разработка.

В 2025 году событие пройдёт во второй раз — смотрите в нашем плейлисте, как это было прошлым летом.

До 5 апреля вы можете подать заявку на доклад infra.conf 2025 — для этого нужно заполнить форму.
На этапе заявки достаточно черновых тезисов и общего плана выступления.
Программный комитет будет готов обсудить ваши идеи и предложения. Финальное решение по докладам примем до 20 апреля.

По возникшим вопросам вы можете обратиться  к координатору infra.conf Саше Галкиной.

Не умею работать с руководством: отстаивать границы впихуемости по порученным задачам.

Бизнес всегда будет желать напихать задач полную панамку.

Первым рубежом в обороне и систематизации задач будет оценка и группировка, — это Твоя ответственность. Важно понимать границу между оценкой (примерное представление о размере задачи) и декомпозицией (уже полноценная работа над ней). Процесс уточнения и детализации задач называют грумингом (или backlog refinement), а оценка задач проводится в рамках планирования или специальных встреч. Оценивают задачи в крокодилах, бананах, бутылках — или по классическим методам, например, покеру планирования с использованием последовательности Фибоначчи.

Зачем нужна такая грубая оценка? Чтобы бизнес мог сопоставить трудозатраты с потенциальной ценностью задачи. После этого он может применить фреймворки приоритезации, такие как MoSCoW, ICE, RICE и прочие, чтобы определить, что действительно нужно сделать в первую очередь.

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

Держать бэклог в приоритезированном состоянии — это только полдела. Надо ещё понять, сколько задач команда может физически осилить. Надо понять широту размаха челюсти команды - velocity :) Для этого существует несколько способов оценки, включая оценку в человеко-часах, сторипоинтах, T-shirt sizes и другие.

Velocity — это не просто количество задач за спринт, а сумма их оценок (например, в сторипоинтах) за спринт, а совокупная способность команды выполнять задачи, включая багфиксы, тестирование, митинги и прочую обвязку. В реальности бОльшая часть времени может уходить на поддержку, рефакторинг и другие технические нужды. Поэтому рассчитывать, что 100% ресурсов пойдут на новые задачи, — полный фейл. Не попадись на эту удочку!

Как только команда поймёт своё реальное velocity, станет очевидно, что любая новая задача вытесняет другую. Кому станет очевидно? И команде, и бизнесу. И вот тут начинается меджик — бизнес перестаёт думать, что производительность команды резиновая.

Теперь можно чётко отстаивать границы впихуемости. Если бизнес диктует, что "завтра всё должно быть в 100 раз масштабируемо", CTO не кидается в бой с криками "сейчас запилим!", а чётко объясняет, какие ресурсы потребуются, какие риски возникнут и какие альтернативные варианты возможны. Главное — не просто говорить "нет", а предлагать реалистичные варианты решения проблемы.

Видишь? Мы отстроили процесс груминга, приоритезации, декомпозиции и оценки задач, взятие в работу только реального объёма бэклога спринта, и внезапно — у нас резко наладились отношения с бизнесом. Бизнес больше не ждёт чудес, команда работает без авралов, CTO перестаёт быть мальчиком на побегушках.

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

• Затраты на поддержку вырастут → Дороже обслуживать.

• Продукт становится нестабильным → Клиенты уйдут к конкурентам.

• Отток специалистов → Потери на найме и онбординге.

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

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

П.С. объявляю конкурс на иллюстрацию к этому посту!