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

Финансы, ритейл, соцсети, облака – везде свои тараканы, но требования схожи: чтобы летало и не падало. Балансировка нагрузки – это как фундамент для небоскреба. Криво зальешь – все рухнет. И вот тут стандартный Round Robin, при всей его простоте, часто оказывается тем самым кривым фундаментом.

OLMo — моделька от AI2, разработанная учёными для учёных. Если вы занимаетесь экспериментами над нейронками, это идеальный вариант: весь код и данные, необходимые для тренировки, открыто лежат на GitHub. Более того, выложены даже промежуточные чекпоинты, с очень высокой гранулярностью. Это отличает ее от якобы "открытых" нейронок, которые обычно приходят к тебе монолитным финальным бинарём.

Эта статья — короткий гайд, адаптированный с GitHub создателей нейросети и проверенный на практике.

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

Привет! Это Влад Шевченко, технический директор направления искусственного интеллекта red_mad_robot. Сегодня я хочу рассказать, что из себя представляет протокол MCP от Anthropic — для этого лучше всего создать его аналог собственными руками.

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

Эра мультиагентов? Как LangChain, только на стероидах: протокол Agent2Agent (A2A) от Google + MCP

Представьте себе будущее, где десятки ИИ-агентов от разных производителей легко и безопасно общаются друг с другом. Звучит фантастически? Уже нет! Google только что выпустил революционный протокол Agent2Agent (A2A), способный полностью изменить ваш подход к автоматизации и совместной работе систем искусственного интеллекта.

Почему это важно? A2A позволяет агентам ИИ объединяться, решая задачи быстрее и эффективнее, чем когда-либо. Это значит меньше затрат, выше производительность и, главное — полная свобода интеграции агентов от любых поставщиков.

Хотите узнать первым, как именно работает A2A и почему Google делает ставку на мультиагентное будущее?

Не упустите возможность заглянуть в завтрашний день!

В этой статье мы проведём подробный анализ современных практик frontend-разработки, сравним состояние React и Vue 5 лет назад и на текущий момент, а также попробуем спрогнозировать их перспективность в обозримом будущем с учётом развития LLM моделей и AI агентов. Посмотрим их экосистемы (Next.js и Nuxt, Redux и Pinia), использование в бэкенде, популярность решений в энтерпрайзе, а так же понимание разработчиками и LLM моделями.

Golang Top 15 ошибок

Go – язык простой, но из-за кажущейся простоты многие разработчики совершают одни и те же ошибки, которые приводят к серьёзным последствиям в production. Ниже собраны 20 самых распространённых ошибок при разработке на Golang и рекомендации по их исправлению.

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

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

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

И вот тут начинается моя личная дизайнерская ирония, даже трагедия...

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

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

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

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

Проект Notary, спонсируемый Docker, обеспечивает высокий уровень доверия к цифровому контенту с помощью криптографических подписей. Он гарантирует, что контент не изменен без одобрения автора и что его происхождение подтверждено.

Notary позволяет системам, таким как Docker Enterprise Edition (EE) с Docker Content Trust, устанавливать политику использования только подписанного контента при развертывании. Это делает Notary важным элементом безопасной цепочки поставок Docker, интегрируя безопасность на всех этапах работы.

Давайте посмотрим подробнее, как работает Notary и как его можно использовать на практике.

TL;DR: KIP‑1150 (Diskless Topics) предлагает Kafka писать сообщения сразу в облачное хранилище (S3 и аналоги), минуя диски брокеров. Это сильно экономит деньги и упрощает масштабирование в облаке, но увеличивает задержки и делает Kafka зависимой от облачных сервисов. Отлично для дешёвых, «толстых» потоков логов, но плохо подходит для real‑time систем с миллисекундными требованиями.

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

Меня зовут Виктор Кузённый, и за 15 лет в IT я работал Java‑разработчиком на гособоронзаказ, делал высоконагруженные бэкенды в Кинопоиске, а затем подружился с Serverless в Yandex Cloud, и этот опыт позволил мне познакомиться с разными инструментами разработки, языками программирования, а также инструментами деплоя и управления инфраструктурой.

В статье разберёмся детальнее, что такое IfC, в чём его преимущества и недостатки, а также чем он отличается от IaС и как его дополняет.

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

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

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

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

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

Старый добрый ACID, который спасал нас в монолитах с одной большой базой, здесь уже не помощник. Пытаться натянуть на микросервисы классические распределенные транзакции с двухфазным коммитом (2PC) – это почти всегда путь к страданиям. Представьте: один сервис захватывает блокировку, ждет подтверждения от другого, тот ждет третьего... Чуть что не так – вся цепочка висит, пользователи ждут, система тормозит, доступность падает. Звучит знакомо? Именно поэтому умные люди придумали альтернативу – паттерн, известный как Saga.