Запускайте контейнерные приложения в облаке с Evolution Container Apps 💭
❓ Что за сервис?Evolution Container Apps позволяет запускать контейнерные приложения в облаке, причем для этого не нужно разбираться в Kubernetes или развертывать виртуальные машины. Запуск проиcходит на базе Docker-образов.
🖥 Особенности и преимущества. Возможности сервиса применимы для любого стека — контейнеры могут использовать любую среду выполнения и любой язык программирования. В зависимости от нагрузки экземпляры контейнеров создаются или удаляются автоматически. Не нужно настраивать кластеры Kubernetes: достаточно загрузить Docker-образы в реестр и создать контейнеры в личном кабинете. А еще у Evolution Container Apps есть free tier: ежемесячный объем бесплатных ресурсов — 480 ГБ RAM и 120 vCPU, запускать небольшие приложения можно без оплаты.
👨💻 Кому будет полезно. Всем, кто использует Docker и хочет облегчить развертывание и масштабирование:
Разработчикам и DevOps-инженерам, чтобы быстро тестировать и запускать приложения.
Небольшим компаниям и стартапам, которые хотят сэкономить на инфраструктуре и попробовать бесплатные возможности Evolution Container Apps.
Большим проектам с микросервисной архитектурой, чтобы облегчить оркестрацию, развертывание сложных приложений за счет контейнеров sidecar и init.
Хотите узнать больше о сервисе? Смотрите запись доклада с GoCloud 2025, где мы рассказали, как сохранить данные в S3 при работе с Evolution Container Apps. А еще сохраняйте пошаговый туториал, как запустить облачное приложение с Evolution Container Apps, без Kubernetes и развертывания ВМ.
Вы сидите на холодном складе в грязном квартале Мишен в Сан-Франциско. День за днем управляете роборуками через перчатки с трекингом движений. Медленно, с усилием складываете одежду и собираете коробки — все ради одной цели: научить нейросеть действовать в реальном мире.
Добро пожаловать в штаб-квартиру Physical Intelligence, стартапа, основанного выходцами из DeepMind. Их цель — не чат-бот, а универсальный робот, способный взаимодействовать с физическим миром, как человек.
Но в отличие от разработчиков ChatGPT, они не могут положиться на залежи интернет-текстов. Посты с Reddit и статьи из Википедии не научат машину держать чашку или гладить рубашку. Сенсорику, телеметрию и управляющие сигналы приходится собирать вручную. Человек, словно кукловод, ведет за собой робота, формируя эталонные движения и реакции. Это медленно, дорого и плохо масштабируется: один оператор не может "наработать" больше 24 часов данных в сутки.
Теперь переместимся на конференцию AI Ascent 2025, где выступает Джим Фан из NVIDIA. Он показывает, как в симуляции за два часа можно пройти путь, на который в реальном мире ушло бы десять лет: гуманоидные роботы учатся двигаться в виртуальной реальности.
Но главное — не это. Фан говорит о том, что он называет физическим Тестом Тьюринга:
Попросите убраться и приготовить обед. Если вы не сможете отличить, кто это сделал — человек или робот — тест пройден
Пока этот тест не прошел никто. Потому что нейросети по-прежнему не имеют телесного опыта этих действий. Это ключевая мысль, тем более что звучит она от директора по ИИ в NVIDIA.
Языковые модели вроде GPT, Claude или Gemini живут в пещере Платона. Они изучают мир по теням — по текстам, изображениям, аудио. Они видят описания, но не проживают реальность.
Настоящий интеллект не просто вычисляет. Он чувствует и действует. Он обретает тело, через которое познает: ошибки, сопротивление, вес, равновесие, трение, успех. Все это — то, что философы называют qualia — субъективные, необъяснимые переживания, формирующие "я". Вот почему так важно дать роботам, например, осязание.
Чтобы пройти физический Тест Тьюринга, машине нужно не больше слоев и токенов, а тело и среда, в которой она учится. Как у детей: игрушки, касания, падения, неожиданности. Ведь и наш мозг формируется не текстами, а опытом.
Но правда в том, что и мы сами смотрим на тени на стене пещеры. Они фактурные, цветные, пахнущие, — но физики напоминают: вселенная гораздо сложнее, чем подсказывают чувства.
А каким будет разум, способный чувствовать тоньше? Острее? Через десятки сенсоров, которых у нас нет, через сигналы, которые мы не в состоянии воспринять? Возможно, путь к сверхразуму — не в вычислительной мощности, а в сенсорной плотности. В телесности. В новых каналах восприятия и способах взаимодействия с миром, которые для нас недоступны.
Будет полезна всем, кто хочет попрактиковаться в комбинаторике на графах и лучше понять, как устроены остовные деревья.
Условие
Тирекс построил собственный дата-центр и теперь хочет объединить 15 серверов в одну сеть. Он не задумывается о надежности топологии, поэтому хочет использовать минимально возможное количество кабелей — 14.
Схема дата-центра Тирекса.
Задача
Тирекс случайным образом проложил 14 проводов. С какой вероятностью все серверы будут соединены в одну сеть?
Соединять серверы можно только по доступным путям, то есть по заранее проложенным трассам — они заданы в виде неориентированного графа, где вершины — серверы, а ребра — возможные соединения. Все соединения — двусторонние, то есть провода не имеют направления.
Предлагайте свое решение в комментариях. А правильный ответ можно подсмотреть в Академии Selectel.
Продолжаю по мере сил пополнять базу проекта NotCVE информацией о проблемах безопасности, которым разработчики не желают присваивать CVE (делал заметку об этом проекте). В этот раз одна проблема в компиляторе Go привела к регистрации сразу 2-х записей:
Т.к. помимо самого компилятора Go, пострадал и Kubernetes:
The Go team has released a fix in Go versions 1.21.11 and 1.22.4 addressing a symlink race condition when using os.RemoveAll. The Kubernetes Security Response Committee received a report that this issue could be abused in Kubernetes to delete arbitrary directories on a Node with root permissions by a local non-root user with the same UID as the user in a Pod.
Из сообщения в гитхабе Kubernetes видно насколько заразительна тенденция вместо регистрации CVE называть фикс проблемы безопасности хардерингом:
The Go team has not issued a CVE for this, as it is considered a hardening issue, and the SRC is following that decision as well.
Собственно, в случае с Docker в этом году было то же самое, для них это тоже хардеринг (моё обращение в MITRE так и не привело к появлению CVE, поэтому я зарегистрировал NotCVE-2025-001).
Как видно, ситуации, когда проблемы безопасности не приводят к появлению CVE случаются не редко. А некоторые разработчики даже пытаются оспаривать назначение CVE.
Приглашаем на первый вебинар из летней практической серии Академии InfoWatch — «Интенсив по анализу событий в DLP-системе: методика и практика». Он пройдет 8 июля с 11:00 до 12:00.
Научим работать с DLP-системой на практике. Покажем, как находить важное даже там, где на первый взгляд все в порядке и в так называемой «серой зоне», где может скрываться нерегламентированная передача информации.
Разберем пошаговую методику анализа событий в зависимости от задачи и отработаем на практике последовательность действий.
Возможно, покажется странным, зачем публиковать, но пока я готовился к поиску новых возможностей и приключений, это начало звучать как кредо. Поэтому подумал почему бы не поделиться?:)
Дисклеймер: На этот раз я не использовал никаких AI тулов для помощи:)
Мои принципы работы:
Этические принципы.
Почему: когда у бизнеса есть определенные принципы разработки программного обеспечения, он обычно отдает приоритет созданию уникальной ценности для конечного пользователя. Это очень помогает в определении того, как команда общается друг с другом, как выглядит и функционирует приложение, как пишется код (задавая ограничения и свободы внутри). Также, имея этические принципы, становится более понятно, когда можно использовать AI (в конечном продукте или в IDE), а когда нет.
Пользовательский и командный опыт.
В своей работе отдаю приоритет влиянию на конечного пользователя и чувству работы в команде при работе с другими людьми.
Значение: ценю опыт других людей и считаю, что культура обмена опытом стоит потраченного времени.
Ценность через заботу и инновации.
Верю, что приложение должно быть простым, сфокусированным и стоить времени людей, которые им пользуются. В сочетании с развивающимися технологиями, особенно с AI (облачными или локальными LLM's), думаю, что очень многое можно переосмыслить и фундаментально пересмотреть, сделав пользовательский опыт приоритетом.
AI:
Использую Cursor (в основном) для написания кода. Но в то же время думаю о AI как о коллеге, который может научить меня новому, переосмыслить старое. В то же время каждое мое решение, где и почему я его использую, основано на этических принципах — это позволяет мне создавать быстрее, но с более высоким качеством для конечного пользователя и разработчика.
Разработчик, дизайнер и QA как пользователь.
На мой взгляд, каждый, кто может получить доступ к коду, тоже является пользователем.
Значение: написание полезной документации, создание полезного API, обеспечение доступности дизайн-системы для дизайнера, получение любой обратной связи (через ревью кода или предварительный просмотр приложения) чрезвычайно важно. На мой взгляд, этот процесс делает лучше не только продукт, но и каждого человека, участвующего в его создании.
Прототипирование.
По моему опыту, многие отличные идеи и практики возникают в результате итераций и быстрого прототипирования — потому что это позволяет не только почувствовать идею, но и поделиться ею, самому испытать ее и поделиться с другими. И получение обратной связи также является важнейшей частью прототипирования 🙂
Тайминг.
Обычно я использую простую формулу, чтобы получить наиболее точное время: Команда + Известные знания + Мой опыт + Мой опыт в кодовой базе | домене.
Значение: при оценке того, как долго может разрабатываться фича/баг/приложение, мне обычно нужно знать людей, которые работают со мной, затем кодовую базу и затем объединить это со всем, что я знаю.
Надеюсь, этот пост вдохновит и окажется полезным в какой-то степени :-)
Пожалуйста, поделитесь своими мыслями в комментариях :-) это поможет сделать эту ветку видимой для других и станет отличной поддержкой и мотивацией :-)
Скачать. Бесплатно, установка не требуется. Кому нужно видеть код приложения - смотрите. Может ругаться Виндовс антивирус, потому что программа без лицензии. Если кто может с ней помочь - прошу написать. Ни на что не претендую, если больше нравится Обсидиан - рад за вас, но не искренне.
Новое в "Заметках с котом":
- все ИИ-функции по отдельным заметкам теперь открываются при нажатии по коробке.
- добавлены функции для пакетной обработки содержимого папок (волшебная палочка при наведении на папку)
- теперь можно быстро открывать и большие файлы.
- можно менять цвета папок в Избранном. Рекомендую добавить в Избранное хотя бы одну папку.
Исправлены ошибки:
неправильное распознавание кодировки. Оставил только utf-8 и windows-1251 - повысил точность их распознавания.
сбой пути при сохранении новой заметки
изредка ии-функции выдают ошибки, теперь их видно (раньше были скрыты)
Разберёмся, где заканчивается компонент и начинается сервис, как уменьшить связанность и повысить читаемость. Завершим практикой: проведем пошаговый рефакторинг на реальном примере.
📅 Дата: 11.07.2025
⏰ Время: 17:00-18:30 (Мск)
На вебинаре:
✔️ Разделение ответственности между компонентами и сервисами
✔️ Уменьшение связанности и повышение читаемости
✔️ Паттерны и антипаттерны в архитектуре Angular
✔️ Практический рефакторинг на примере «грязного» компонент
👨🎓 Спикер: Погорелов Павел — эксперт в области фронтенд-разработки.
Узнайте, как выстроить архитектуру Angular-приложения, которая выдержит рост команды и кода!
Одной из особенностей любого опенсорс-проекта является проблема управления этим проектом. Человек с ключами от главного репозитория и с правами на управление сайтом и/или мобильными сторами имеет возможность осуществлять действия, которые не будут пользоваться поддержкой иных участников (контрибьюторов) данного проекта.
Например, владельцу продукта может придти в голову идея внедрить жесткую монетизацию каких-либо фичей, или вставить рекламу, или изменить условия лицензии на часть кода, сделав её проприетарной, а не свободной.
Случившийся в марте конфликт между сооснователями проекта Organic Maps стал тем триггером, который запустил создание комьюнити-форка проекта, над которым начали работу часть бывших контрибьюторов Органикмапса.
Так появился проект CoMaps - полностью оффлайновые и бесплатные карты для мобильных устройств с фокусом на приватность: в приложении нет каких-либо трекеров, мы не собираем и не передаем кому-либо каких-либо данных.
А приставка "Co" намекает, что это именно community-driven проект, где ключевые решения принимаются после обсуждения внутри всего сообщества контрибьюторов и при необходимости - после сбора мнений путем голосования за тот или иной вариант.
За прошедшие три месяца команде разработчиков удалось наладить стабильную сборку приложения и карт из OpenStreetMap, провести доработку части функциональности приложения. Например, добавили изолинии (рельеф) с шагом 100 метров для всех возможных территорий, сделали локальный бэкап меток и записанных треков, изменили на более удобный для восприятия (ну, нам так кажется) картостиль.
Дальнейшее развитие проекта предполагает как развитие текущих и создание новых фичей на основе сбора обратной связи от самих пользователей, так и формализация самого статуса проекта. Прямо сейчас мы обсуждаем и рассматриваем разные варианты, в том числе создание "нон-профит" организации; или же можем придти под крыло какой-нибудь известной организации вроде SFC или подобной.
Так как сегодня, 3 июля 2025, мы сделали первый публичный релиз приложения в сторах, приложу пачку ссылок на ключевые ресурсы проекта:
https://comaps.app - сайт проекта (там можно найти всю рабочую внутрянку - матрикс/телеграм/zulip чаты, репозитории, таск-трекинг, инструкции как присоединиться к разработке со своими идеями, и т. д.)
Случайна ли случайность? Теория вероятности и личный опыт
Все мы когда-то слышали или читали, что кто-то где-то выиграл джекпот. Столько-то миллионов рублей или долларов, не имеет значения. Важно то, что этого никогда не случится с нами, потому что вероятность этого события – 1 на сотни миллионов.
Однако, со мной кое-что случилось, что, мне кажется, в соответствие с теорией вероятности случится не должно было никогда. И этим оно напоминает джекпот.
На старших курсах ВУЗа проходил практику в школе своего города, который расположен ровно в 1 000 км от Москвы. Преподавал естественные дисциплины школьникам 5-9-х классов. Не суть, что там было по учёбе, главное, что в одном из 9-х классов учился юноша, который в следующем учебном году, т.е., уже осенью, должен был уехать с родителями в Москву. Юноша упомянул как-то про это, и мы даже разговорились с ним, потому что я сам через несколько месяцев собирался уехать в Москву на стажировку. Для нас обоих это был совершенно новый, неизведанный мир. Одно слово - столица!
Наступила осень. Приехала в гости к молодому стажёру мама и я повёл её в театр. И вот садимся мы на свои места, а рядом, на соседнем месте оказывается… тот самый юноша, уже московский десятиклассник, с которым мы полгода назад болтали непринуждённо про столицу нашей Родины.
В пекло теорию вероятности! В соответствии с ней описанное выше событие не могло произойти со мною в принципе. А оно было. И это реальный факт, который до сих пор помню.
Вот так я выиграл свой «джекпот», за несколько сотен рублей, которые стоил билет в театр в далёком 1992-м году. Правда, выигрыш в том «джекпоте» достался мне небольшой, точнее сказать, ничего не досталось, кроме улыбки и взаимного удивления невероятному стечению обстоятельств. Но, надеюсь, что для одного небольшого поста на Хабр этого хватит.
И, конечно, было бы интересно оценить вероятность описанного выше события, однако, я затрудняюсь даже с направлением, с какой стороны следует подступаться к такой оценке, не то, чтобы какими-то цифрами оперировать.
Тут, думаю, нужны кругозор и хватка многоопытного актуария или серьёзного аналитика, для которого подобные задачки – как семечки щёлкать. Есть ли такие на просторах Хабр?
Открыта регистрация на Kubernetes Community Day — главную сходку K8s-сообщества
31 июля в Москве состоится первая независимая конференцияKubernetes Community Dayдля открытого сообщества профи по куберу и тех, кто только начинает. Два пространства с техническими докладами, дискуссиями и хардкорными воркшопами, интерактивы и IT StandUp. Никаких HR-стендов и дорогих билетов — только бесплатное участие, сообщество, живое общение.
Цель мероприятия — создать площадку для объединения сообщества, обмена опытом и нетворкинга. В программе — актуальные выступления от коллег из различных компаний, которые дышат контейнерами: Yandex Cloud, ecom.tеch, VK, Luntry, МКБ, «Лаборатория Числитель», Lamoda Tech, Rebrain, Cloud ru и др.
Как роботы стали частью культуры — и почему это важно сегодня
Мы привыкли думать о роботах как о технологиях будущего. Но на самом деле им уже больше 2 тыс. лет — по крайней мере, как идее. Механические существа появляются еще в мифах Древней Греции: автоматоны Гефеста, живые статуи и железные помощники — первые прообразы современных роботов.
Что изменилось с тех пор? Почему человечество так настойчиво мечтало о разумных машинах? И как художники, философы, писатели и инженеры вместе формировали наш образ «искусственного человека»? Ответы на эти вопросы — в лекциях YADRO Lectorium от экспертов Сколтеха, «Иннополиса» и Музея криптографии.
«Спросите любого робототехника, как он пришел в профессию — он вспомнит не тему своего диплома, а первую игру, первый конструктор, первый мультик про роботов», — Егор Ефремов, культуролог, историк техники, исследователь в Музее криптографии.
В статье собраны лекции YADRO Lectorium — о культурной эволюции образа робота, текущем состоянии и трендах в мировой робототехнике, а также о том, как физический дизайн влияет на функциональность и взаимодействие человека с машиной.
Кто-то боится регулярных выражений, а потому избегает их. Кто-то пользуется этим инструментом и решает с его помощью сложные задачи. Мы подумали, что хорошо бы собрать полезные статьи по этой теме в одном месте и помочь читателям избавиться от «регекспофобии». Ну или, наоборот, усугубить ее — тут уж как получится.
В курсе разберем не только базовый синтаксис, но и осветим темы посложнее. Посмотрим даже, как можно комментировать регулярки в движках, которые не поддерживают такую функциональность. Уделим особое внимание работе с кириллицей. Все разбираем на примерах.
После изучения материалов вы сможете:
моментально извлекать данные из гигабайтов текста;
валидировать формы любой сложности;
правильно обрабатывать тексты на русском (никаких сломанных \b);
решать сложные задачи с помощью lookarounds и именованных групп;
повысить свой уровень в работе со скриптами и редакторами.
Все материалы бесплатные. Не требуется даже регистрация.
Основа Kotlin K2 компилятора — это FIR‑дерево (Frontend Intermediate Representation).
Вкратце: FIR — это AST (абстрактное синтаксическое дерево), обогащённое семантической (смысловой) информацией. Оказывается, что у этой основополагающей технологии есть своя небольшая документация: fir‑basics.md и в той части, где написано про контракты указано (в моём вольном переводе), что:
Компилятор разрешает использовать контракты в свойствах, функциях и конструкторах классов
Вот это поворот! Ведь ранее было замечено их использование только внутри тела функций. В доке написано, что для свойств должно работать, но на практике получаем ошибку.
А где находится то самое ограничение на использование контрактов вне функций описал Android‑разработчик Виталий Перятин в новой статье о Kotlin Contracts, где он поделился любопытными моментами, которые удалось накопать самостоятельно, потому что как парсится список эффектов, как работает новый Contracts API изнутри, и почему, чёрт возьми, на уровне компилятора можно использовать контракты не только на уровне функций, в доках не пишут.
Совершенный assert() для всех языков программирования
...как ни смешно, но пострадали стоматологи: стало меньше зубовного скрежета!
Когда C/C++ разработчики переключаются на другие языки, им очень не хватает привычного механизма assert()/NDEBUG. Он, в некотором смысле, позволяет получить "идеальный" метод управления Debug/Release конфигурациями:
Как вы правильно поняли, в Release конфигурации строки кода между #ifndef NDEBUG и #endif полностью исчезают, и мы получаем идеальный билд. Но идентичного результата можно добиться и с помощью комментариев... (здесь должна была быть картинка, но вставить не получается)
Гмм.. Значит будет лишь краткий конспект статьи.
ОК, как ни странно, но это правда: я создал утилиту DebRel, полезную ВСЕМ языкам программирования! Комментарии специального вида (D0 - D9 и R0 - R9) позволяют минимальными усилиями добиться "идеального" управления Debug/Release конфигурациями:
Debug конфигурация дает нам всю необходимую диагностику! С различной глубиной.
В Release конфигурации нет никаких следов Debug-а! Ни байта.
А именно:
Конфигурация RN отменяет все остальные. Релиз -- эгоист!
Конфигурация DN оставляет лишь строки от D0 до DN. Вы задаете глубину отладки.
Контур проводит исследование о том, как живёт .NET-сообщество в России. Анкета активна до 15 июля.
Вопросов чуть больше 20, но большинство из них закрытые, так что много времени не займет. Мы не спрашиваем ваши персональные данные и зарплатные вилки. Мы хотим узнать, как C# разработчики обмениваются знаниями и какие выбирают инструменты для развития.
Как я случайно сделал ферму в Telegram с помощью ИИ
— История одного бота, картошки и чёртовой тыквы
Всем привет. Я — человек, который однажды хотел просто сделать прикольного бота в Телеграме, а в итоге... выращивает капусту, торгует молоком и организует тыквенные войны.
Но началось всё, как ни странно, с Таро. Да-да, карт Таро. Тех самых.
Первая попытка: гадать и страдать
Где-то в начале года я решил сделать Telegram-бота, который бы умел раскладывать карты Таро, делать натальные карты и выдавать предсказания на день. Казалось бы, звучит просто. Особенно если рядом есть ChatGPT, который может на ходу генерировать описания карт и писать код на Node.js.
Зарядка с утра: — GPT, напиши функцию для расчёта Луны в Скорпионе. — GPT, как сделать inline-кнопки в grammY? — GPT, почему Heroku опять всё уронил?
И вот бот заработал. Люди заходят, тянут карту дня, шлют благодарности… и уходят. На следующий день — снова тяни карту. Через неделю — всё. Надоело.
Я понял: бот с Таро работает, но удержать людей в нём сложно. Там нет жизни. Там нет... морковки.
А потом я вспомнил старую ферму
Когда-то, ещё во времена динозавров и ВКонтакте, у меня была ферма. Та самая, где каждый день надо было заходить, собирать урожай, сажать заново, а если не успеешь — тебя вытопчут друзья с соседнего класса.
И вот я подумал: а что, если скрестить эту старую добрую механику с Telegram-ботом?
Чтобы всё было просто:
Никаких установок
Играть можно прямо в чате
И чтобы всегда был шанс насадить кукурузу, а не просто наслаждаться жизнью
Начало новой жизни
Запустил первого бота. Добавил регистрацию, посадку капусты и сбор. Подключил базу PostgreSQL. Всё это — руками и с подсказками ИИ (да здравствует Cursor AI, GPT и граммY).
Первый баг — бот забывал, что ты уже посадил картошку. Второй баг — тыква, которую почему-то можно было доить. Третий баг — не баг, а фича: игроки начали просить рынок, коров и возможность топтать грядки друг другу.
Так появилась Веселая Ферма — ферма прямо в Telegram, которая сейчас уже живёт своей жизнью, где игроки сажают растения, разводят скот, воруют другу у друга лимоны и спорят в чате, почему мед дешевле мотыги.
Что дальше?
Это только начало. Я хочу рассказать:
Как ИИ помогает не сойти с ума, когда у тебя 500+ игроков и баг в 3 ночи
Как запускались тыквенные фестивали и почему это был трэш
Как устроен баланс в экономике фермы
И как создать клановую систему, когда никто не читает туториал
Если интересно — подписывайся на продолжение. А если хочешь сам потыкать бот — вот: 👉 Веселая Ферма
Следующая часть будет про то, как я балансировал экономику в игре, используя google sheet, интуицию и крик в подушку, почему Доярка Жанна названа в честь жадной хозяйки квартиры, и откуда взялся Председатель СНТ в образе Якубовича.
