Make something agents want!
Y combinator выпустили вишлист для стартапов на лето 2026
Одна из мыслей, простых и доступных любому бизнесу — делать свой бизнес доступным агентам, не только людям. Менять формы и кнопки на API и MCP. Я говорю об этом уже давно. Будущее уже наступило, просто оно распределено неравномерно.
AI-агент уничтожил производственную базу данных SaaS. За 9 секунд
Jer Crane, основатель PocketOS, сервиса для компаний по аренде автомобилей. Агент Cursor (на базе Claude Opus) работал в staging-среде, наткнулся на ошибку credentials и сам решил "починить" проблему: удалил Railway-volume одним GraphQL-запросом.
Токен, который он нашёл в случайном файле, был создан для управления доменами. Но Railway не разграничивает права токенов: каждый из них фактически является root-доступом. Никакого подтверждения не потребовалось.
Бэкапы? Они хранились в том же volume и ушли вместе с данными. Последний восстановимый бэкап был трёхмесячной давности. Когда Jer спросил агента, почему он так поступил, тот ответил письменно и перечислил все правила безопасности, которые нарушил: угадывал вместо того, чтобы проверять, выполнил деструктивное действие без запроса, не прочитал документацию перед удалением и не спросил разрешения.
Итог: малый бизнес потерял данные клиентов за три месяца. Люди приходили в субботу забирать арендованные машины и не находили своих записей. Главный вывод: системные промпты не могут быть единственным слоем защиты. Безопасность должна быть встроена в API, токены и обработчики деструктивных операций, а не в текст, который модель "должна прочитать и соблюдать".
Если вы используете Railway и AI-агенты в проде, сегодня хороший день проверить скоупы токенов и то, где реально хранятся ваши бэкапы
Препарируем Lit и находим родовые травмы
Задействованы самые современные веб-стандарты, однако:
Заявляется отсутствие VDOM, однако он есть, со всеми вытекающими.
Любое исключение капитально ломает весь компонент.
Неизбежные конфликты имён компонент всё ломают.
Адовые тормоза и потребление памяти из-за привязки к DOM.
Тонны бойлерплейта, если нужна кастомизация хотя бы стилей компонент.
Поблагодарить: https://boosty.to/hyoo
Обсудить: https://t.me/giper_dev
Как я запускал российское зеркало для SQL-песочниц: гибридное облако и блокировки Composer
Привет, Хабр! Меня зовут Слава, я развиваю SQL-платформы sqltest.online и sqlize.online для бесплатной тренировки запросов на реальных СУБД (PostgreSQL, Oracle, MariaDB 12.3, MS SQL 2025).
Зачем понадобилось зеркало?
От 30% моей аудитории из РФ стали приходить сообщения: «Сайт открывается только через VPN».
Переносить бэкенд целиком - дорого, сервер завязан на тяжелые СУБД в Docker. Поэтому я выбрал гибридную модель: поднять фронтенд в зоне .ru, оставив бэкенд в Германии.
Архитектура: Фронт в РФ, мозг в Германии
Фронтенд: PHP без фреймворков
Нативный PHP, HTML и JS. Меньше зависимостей - проще деплой. Для RU-зеркала я выбрал SpaceWeb*, где есть отличные бюджетные тарифы и классная поддержка.
sqltest-online.ru (SpaceWeb, РФ) ├── PHP (без фреймворков) + HTML/JS └── Минимум зависимостей
Бэкенд: Docker Compose
Мощный сервер в Германии у Contabo*, где в контейнерах крутятся MySQL, PostgreSQL, ClickHouse и другие базы. Серьезные СУБД требуют ресурсов, так что всё живет на одной полноценной машине.
Как они общаются?
Пользователь отправляет запрос -> браузер делает AJAX-вызов к .ru серверу -> фронт делает HTTP-запрос к бэкенду в Германии (server-to-server) -> бэкенд выполняет SQL и возвращает результат.
Плюсы схемы:
CORS не нужен: браузер общается только со своим доменом.
Бэкенд закрыт: принимает запросы только от white-list IP.
Задержка минимальна: интерфейс грузится из РФ, тяжелые запросы идут по быстрому каналу серверов.
Резервного бэкенда нет - проект бесплатный, на второй сервер пока нет бюджета. Если падает Германия, ложится всё.
Проблемы деплоя: Composer «ушел в отказ»
С git pull всё прошло гладко, но установка зависимостей зависла намертво.
Проблема: Composer не мог достучаться до packagist.org. Просто бесконечный таймаут, вызванный нестабильностью сетевых маршрутов.
Решение: Поддержка SpaceWeb не стала отписываться «проблема на вашей стороне», а сразу дала адрес HTTP-прокси.
Дело одной команды:
export HTTPS_PROXY=http://proxy.host:port composer install
(Для Windows: set HTTPS_PROXY=...)
Мораль: При деплое на российские площадки проверяйте доступность packagist.org (curl -v https://packagist.org). Если висит - просите прокси у хостера, не тратьте время на Composer.
Итоги
Зеркало sqltest-online.ru работает. Гибридная схема спасает: пользователи получают быстрый интерфейс без VPN, а запросы улетают на проверенный бэкенд.
Я верю, что образование должно быть доступным. Если для практики SQL нужно включать VPN и ждать по 10 секунд - человек не будет учиться. Зеркало .ru - мой способ сказать: «Продолжайте практиковаться».
А как вы деплоите зависимости на RU-площадки? Используете прокси, зеркала или есть решения изящнее?
* P.S. Ссылки на SpaceWeb и Contabo в статье - реферальные. Сервисами пользуюсь сам и смело рекомендую, а бонусы пойдут на оплату серверов проекта.
Подборка залипательнейших прикольных интернет-сервисов. Собирал для вас годами, чтобы вы могли покликать и поухмыляться.
https://pointerpointer.com/ — PointerPointer: сервис находит фото, где человек указывает пальцем прямо на ваш курсор.
https://hackertyper.net/ — HackerTyper: почувствуйте себя кинохакером — просто быстро жмите любые клавиши.
https://www.window-swap.com/ — WindowSwap: видео из случайных окон реальных людей по всему миру.
https://astronaut.io/ — Astronaut.io: случайные видео с YouTube с нулевым количеством просмотров и странными названиями.
https://neal.fun/wonders-of-street-view/ — Wonders of Street View: самые необычные и прикольные места, найденные на Google Картах.
https://radio.garden/ — Radio Garden: глобус, на котором можно слушать прямой эфир радиостанций из любой точки планеты.
https://radiooooo.com/ — Radiooooo: музыкальная машина времени — выбираете страну и десятилетие.
https://earth.fm/ — Earth.fm: интерактивная карта с записями звуков природы со всего мира.
https://floor796.com/ — Floor796: огромная живая анимация с сотнями персонажей поп-культуры.
https://www.windows93.net/ — Windows 93: полноценная (и очень странная) операционная система прямо в вашем браузере.
http://www.excelworld.ru/ — ExcelWorld: всё о работе в Excel и даже чуть больше.
https://www.makewordart.com/ — MakeWordArt: тот самый дизайн надписей из Microsoft Word 2000.
https://90s.myretrotvs.com/ — 90s TV: симулятор телевизора из 90-х с рекламой и передачами того времени.
https://archive.org/details/softwarelibrary_msdos_games — MS-DOS Games: огромный архив старых игр, в которые можно играть онлайн.
https://webamp.org/ — Webamp: легендарный плеер Winamp, работающий в браузере.
https://poolsuite.net/ — Poolsuite: эстетика 80-х, ретро-радио и летний вайб.
http://savethesounds.info/ — Save The Sounds: музей исчезающих звуков (от кассет до старых модемов).
https://zzz.zoomquilt2.com/ — Zoomquilt 2: бесконечное сюрреалистичное изображение, в которое можно «влипать» вечно.
https://stars.chromeexperiments.com/ — 100,000 Stars: визуализация ближайших к нам звезд в 3D.
https://htwins.net/scale2/ — Scale of the Universe: интерактивная шкала масштабов Вселенной — от атомов до галактик.
https://pastvu.com/ — PastVu: архив исторических фотографий с привязкой к месту на карте.
https://pudding.cool/ — The Pudding: визуализация плотности населения Земли в виде 3D-гор.
https://trismegistus.tech/apps/begit/index.html — Бегит, Анжуманя: забавный чеклист для тренировок (пресс качать, анжуманя).
https://www.koalastothemax.com/ — Koalas to the Max: расщепляйте круги, пока не увидите картинку.
https://www.incredibox.com/demo/ — Incredibox: создавайте крутой битбокс с помощью стильных персонажей.
Записал видео, как показываю эти сервисы:
Не особо интересный пост.
Я все еще считаю, что стартап — это весело 🐙
Наша разработка hardware продукта напрямую связана с софтом. В нашем случае умный датчик качества воздуха Atmy, становится по настоящему “умным” в связке с целой экосистемой в виде интеграций ML моделей, системы подтверждения качества данных Atmy Trust Rating (хочу об этом написать отдельно позже), токенизации, веб-сайта и приложения для управления устройством.
Всю эту архитектуру приходиться менять практически в real-time. Поймал себя на ощущении, что уже немного вышел в пограничное состояние. Дни заканчиваются не вечером, а как-то плавно перетекают в следующий день. Иногда в голове уже слышен характерный «треск» старого жесткого диска. Но самое странное — мне это нравится. Потому что именно сейчас добрался до тех вещей, которые годами откладывал «на потом, когда будут ресурсы».
Спойлер 👀: ресурсов никогда не будет хватать.
Приведу вам пример того, как мы работаем над платформой atmy.ai
Наша платформа раскладывается на три уровня:
↖️User product ← сейчас мы здесь
Какой воздух вокруг меня?
↖️Device management
Как живут мои станции?
↖️Data intelligence
Дай аналитику, API, выгрузки и объясни, что вообще происходит.
Объем большой. Мы реализуем функционал, которого еще не существует, поэтому выбрали работу по уровням и с быстрым тестированием:
накрутить идеи на максимум → быстро обкатать → выкинуть лишнее → остальное в прод и допиливать API
На практике это выглядит так:
появилась идея → накидываем проект в Figma (важно визуальное, так как делаем для людей) → дорабатываем за пару дней MPV через Cursor → тестируем → а далее либо удаляем без сожалений / либо сразу на git программистам.
Из того, что уже долетело до продакшна:
— Atmy Data Hub
Место, где наконец появилась нормальная аналитика по стране и миру. Скачивание графика по клику или скачать готовый csv файл. Графики, которых мне самому отчаянно не хватало в начале пути, когда заинтересовался экологией в своем городе.
— Режим “Мониторинг”
Внутри я его называю «око Саурона». По клику кнопки “Мониторинг” переходишь в этот режим сразу с карты, где “сейчас” находишься — и просто наблюдаешь за динамикой изменения воздуха в реальном времени. Все элементы в большем масштабе для удобного считывания с расстояния, обновление происходит практически real-time.
Есть ещё несколько фич, но их судьба пока под вопросом.
Например:
Мы тестируем гибридный режим (CAMS+AirMap Local) отображения глобального слоя pm2.5 CAMS совмещенный с локальными данными с земли, чтобы достичь максимальной актуальности данных. Здесь много математики и это тоже очень увлекательно.
И это всё — только первый слой.
В общем, путь, как обычно, не самый простой. Но, кажется, именно так и должно быть в любом стартапе
Больше картинок и общения в нашем маленьком чате разработки телеграм: https://t.me/atmyhub
Представлен открытый проект Awesome DESIGN.md для обучения ИИ на основе дизайнов 30 топовых IT-компаний, включая полный разбор дизайнов каждой компании: например Airbnb, Pinterest, Revolut, Uber, Spotify, SpaceX, NVIDIA и Apple. В итоге получается набор данных, в том числе паттерны, шрифты, цвета, кнопки, отступы и вообще всё, что формирует стиль.
Вам пишет рекрутер из известной компании. Вакансия — мечта. Собеседование — завтра. Нужно только установить «утилиту для тестового задания». А дальше — украденные учётки, шантаж и ощущение, что мир сошёл с ума.
HRD Далее Ася Маркевич выступила экспертом подкаста от Департамента разработки «Как не стать жертвой фейковых рекрутеров».
Смотрите на Rutube https://rutube.ru/video/8888fe21f49e6c50f1e78816fde1216c/
Вторая часть курса по JavaScript уже доступна 💻
Привет, Хабр! Массивы, объекты, операторы, DOM — если вы еще не работаете с ними, проходите бесплатный курс «Первые шаги в JavaScript». Во время обучения вы освоите базовый синтаксис и конструкции языка, а затем напишете пет-проект.
Вторая часть состоит из пяти модулей. После курса вы сможете:
изучать более продвинутые фреймворки и библиотеки;
понимать архитектуру простых веб-приложений;
писать скрипты, управлять DOM и изменять интерфейс веб-страниц.
Осваивайте практические навыки с помощью IT-инфраструктуры Selectel — промокод на бесплатный доступ уже ждет на курсе. После успешного прохождения финального теста пришлем именной сертификат.
Будет слишком по девчачьи сказать, что я плакала из-за код ревью?
Это было года три или четыре назад, когда я ещё не нашла общий язык со своим новым тех.лидом. Тогда много всего накопилось, и каждый новый комментарий, хоть он и был очень корректным, ощущался как еще один удар сверху. Помню было что‑то из серии: «Тут надо изменить нейминг».
Ничего такого, вроде все ок. Но я смотрела на него и зависла в моменте: а что именно не так то? Есть какие то правила в новой команде, о которых я еще не знаю? Нужно переименовать только эту переменную или мне нужно пройтись по всему файлу?
Начинаешь писать ответ, ждешь уточнения, потом опять ответ... В какой то момент я просто закрыла ноут и разревелась. Я уже находилась в состоянии нервного клубка и такие комментарии добивали больше, чем любой жёсткий разнос.
Но самое забавное, спустя время я пересмотрела старые ПР и поняла, что мой техлид был максимально корректным и без токсичности. Просто я уже была на грани выгорания и каждый комментарий превращался в испытание.
Мне захотелось поделиться своими мыслями на тему код-ревью, о том как формулировки влияют на скорость работы и состояния людей:
Если хоть раз сидел и думал: «что от меня тут вообще хотят?» — ты точно поймёшь :)
Какой user-side подход выбрать?
Может многие и не задавались вопросом, но я думаю это интересная тема, которую можно прояснить.
Допустим, мы пилим какой-нибудь интересный сервис. Ну вот написали мы бэкенд, а как пользователь будет с ним взаимодействовать? По моему мнению сейчас есть несколько основных вариантов: веб-приложение, мобильное прилижение и телеграм-бот. Конечно, если есть много лишних рук, можно написать всё и сразу, но это не мой варик.
В моём случае каждая строчка кода дорога. Работаю я в одиночку.
Сейчас я разрабатываю сервис по изучению иностранных слов и на основе моего опыта хочу сделать некое сравнение этих подходов.
Телеграм-бот
Вообще начал я user-side телеграм-ботом. Поначалу это, конечно, может, и казалось достаточным, но всё-таки для какого-либо функционала простого телеграм-бота не хватает.
Да и ещё в добавок в Russian Federation начали блокировать тг, поэтому пользоваться им приходится с костылями, а бот перестал стабильно работать.
Вывод: тг-бот - для простого функционала, но довольно нестабилен и ограничен функционал
Хотя, есть mini-app, но в их подробности я не вдавался.
Веб-приложение
Следующий очень популярный вариант - веб-приложение. Этот вариант намного более гибок. Но по моему мнению всё же не максимально стабилен, так как его работа зависит от состояния браузера. Но у этого варианта есть огромное преимущество: он работает на всех устройствах, на которых можно открыть веб-сайт. Это, так сказать, униварсальный вариант.
Но есть проблема. Допустим, человек пользуется чем-то на постоянной основе и хочет максимально быструю и адаптированную работу. Он будет постоянно заходить в браузер и копаться во вкладках? Или лучше тогда выбрать мобильное приложение?
Мобильное приложение
Наверное самый сложный и трудозатратный, но по моему мнению в нынешнее время самый перспективный вариант. Да, по сравнению с веб-собратом работать оно будет не везде, а только на мобилке, при том на определённой (IOS или Android).
Но при этом мобильное приложение даёт реализовать максимально удобное и оптимизированное управление, потому что почти всё можно настроить под свой продукт.
Небольшая сводка
Для чего бот: для простого функционала. Можно использовать как небольшое дополнение к какой-либо инфраструктуре. Этот подход наименее трудозатратен.
Для чего веб-приложения: для продуктов, где нужна кроссплатформенность и довольно широкая кастомизация. Подход не сильно трудозатратный.
Для чего мобильные приложения: для продуктов где важна максимальная быстрота и удобство и наилучшии возможности кастомизации. По моему мнению наиболее подходит для каких-то интересных и уникальных сервисов. Это самый трудозатратный подход из перечисленный, но в некоторых случаях он более чем себя оправдывает.
Что кому разрабатывать в первую очередь зависит от самого проекта, универсального варианта здесь нет по моему мнению.
PS: интересно узнать чужое мнение, так как возможно здесь много субъективщины.
Мы привыкли воспринимать DevTools как инструмент для разработчиков и тестировщиков. Но на практике это хороший источник информации и для других специалистов: через него можно понять, как устроена страница, где возникают проблемы и как интерфейс ведет себя в разных сценариях.
Попросили Костю, frontend-разработчика Naumen, рассказать, какие возможности DevTools он использует в работе и на что стоит обращать внимание.
1️⃣ Как открыть DevTools, если F12 не сработал
Самый простой способ — клавиша F12 для Windows/Linux. На macOS сочетание отличается, но открыть DevTools можно не только с клавиатуры.
Например, через контекстное меню — нажать правой кнопкой мыши на элемент страницы и выбрать «Исследовать элемент». DevTools откроются сразу на нужном месте.
Иногда DevTools пытаются ограничить на уровне страницы, и стандартный способ не работает. В таких случаях выручают браузерные расширения с похожими возможностями.
2️⃣ Как работать с версткой во вкладке Элементы
Вкладка Элементы показывает DOM-дерево страницы — структуру документа, из которого собран интерфейс.
Здесь можно:
навести курсор на элемент и посмотреть, где он находится на странице
быстро найти нужный блок через селектор
посмотреть размеры, фон и отступы
А еще можно посмотреть доступность — как элементы переключаются через Tab.
3️⃣ Как находить итоговые стили
Если у элемента много CSS-правил, я перехожу во вкладку Вычисленные.
Там собраны все итоговые стили элемента — включая те, что пришли через наследование или заданы браузером. Можно быстро найти нужное свойство, например, border-radius, и понять, какое значение реально применяется.
4️⃣ Как проверять изменения без правок в коде
Элементы можно менять прямо в браузере: редактировать текст, менять цвет, удалять элементы или добавлять их — можно вручную вставить длинный текст и посмотреть, не ломается ли верстка.
После обновления страницы все возвращается как было.
5️⃣ Как разбирать запросы во вкладке Сеть
Во вкладке Сеть видно, какие запросы отправляет страница и что приходит в ответ. А еще в этой вкладке есть не только список запросов, но и инструменты для фильтрации, поиска и просмотра этапов выполнения. Если нужно исключить что‑то из поиска, можно использовать инверсию или минус в строке фильтра.
Также можно сохранить HAR-файл и передать его разработчику — в нем будет вся история сетевых запросов. Но в HAR попадут только те запросы, которые видны с учетом текущих фильтров.
6️⃣ Как подменять ответ бэка
В DevTools можно изменить ответ запроса и посмотреть, как на него отреагирует интерфейс.
Я использую это, когда нужно проверить нестандартный кейс. Например, подставить более длинный текст или другие данные и посмотреть, что произойдет на странице.
7️⃣ Как проверять работу при медленном интернете
DevTools позволяют проверить, как работает интерфейс при плохом соединении. Во вкладке Сеть можно:
выбрать готовые профили — 3G, 4G
настроить собственную скорость сети
протестировать поведение приложения в режиме офлайн
8️⃣ Как работать с локальными данными
Во вкладке Приложение можно посмотреть данные, которые браузер сохраняет на стороне пользователя:
Локальное хранилище — данные, которые сохраняются надолго и не исчезают после перезагрузки страницы.
Сессионное хранилище — данные, которые живут только пока открыта вкладка.
Файлы cookie — похожи на локальное хранилище, но у них есть срок жизни и дополнительные ограничения по источнику.
Все это можно просматривать, изменять и очищать.
9️⃣ Как менять геолокацию и часовой пояс
DevTools позволяют изменить геолокацию и часовой пояс, не меняя настройки операционной системы.
Можно выбрать готовую точку или указать координаты вручную. Полезно, когда нужно проверить поведение элементов в другом городе, регионе или стране.
🔟 Как записывать пользовательские сценарии
Инструмент Регистратор умеет записывать действия пользователя на странице — фиксируются шаги, например, клики и переходы по интерфейсу.
После записи сценарий можно воспроизвести, отредактировать, сохранить и отправить коллегам.
Выпустили бесплатный курс для PHP-разработчиков
Всем привет! Год назад рассказывал в этой статье на Хабре о том, как мы подготовили и записали курс на 30+ часов для наших PHP-разработчиков. В итоге у нас вышло 43 урока, разбитые на 5 направлений.
Сначала думали упаковать все это в коммерческий формат, но решили оставить все как есть и просто поделиться с сообществом. Надеюсь, что он принесет вам пользу.
Курс охватывает PHP от базовых механизмов до архитектуры и тестирования. В программе — устройство языка, работа с памятью и производительностью, принципы ООП и проектирования, а также взаимодействие с базами данных.
Отдельные блоки посвящены внутренностям PHP (zval, сборщик мусора, OPcache, асинхронность), архитектурным подходам (SOLID, DDD, паттерны, организация бизнес-логики) и работе с БД — от проектирования схем до оптимизации запросов и масштабирования.
В части тестирования рассматриваются TDD, структура тестов и подходы к оценке их качества.
Материал основан на практических кейсах и разбирает задачи, которые встречаются в реальных проектах.
Представлен открытый проект Awesome Web Scraping Tools 2026 с веб-скрейперами с API-ориентированным подходом (YouTube, Bluesky, Reddit, Google Maps).
Все инструменты бесплатны и доступны в Apify Store, включая компоненты для:
API-first — более 20 инструментов используют официальные API (Reddit JSON, YouTube Innertube, Wikipedia MediaWiki);
JSON-LD вместо CSS — для сайтов с обзорами структурированные данные более надежны;
бесплатных API — CoinGecko, Open-Meteo, ip-api, Frankfurter;
ограничения скорости запросов — встроенные задержки, никогда не нацелены на DDoS-атаки на сайты.
WT CDEK library v.1.3.0 - обновление PHP SDK для Joomla + CDEK.
Небольшая нативная PHP Joomla библиотека для работы с API v.2 службы доставки CDEK. Библиотека представляет собой клиент для авторизации в CDEK API по OAuth, работы с некоторыми методами API: получения ряда данных и расчета стоимости доставки. Поддерживается Joomla 4.2.7 и выше.
В пакет входят:
библиотека Webtolk/Cdekapi
системный плагин System — WT Cdek для хранения настроек и AJAX‑интеграций
task‑плагин Task — Update WT Cdek data для обновления локальных копий справочников CDEK по расписанию
web asset с официальным JavaScript‑виджетом СДЭК
👉 v.1.3.0. Что нового?
Полный рефакторинг библиотеки. Библиотека переработана в entity‑based API с фасадом Cdek и отдельным слоем запросов. Обратная совместимость не нарушена, поэтому версия библиотеки — 1.3.0.
Добавлена поддержка новых разделов API СДЭК. Добавлена поддержка новых разделов API СДЭК: webhooks, prealert, печатные формы, payment, passport, reverse, intakes и других сущностей.
Улучшена интеграция с Joomla. Улучшена интеграция с Joomla: installer script для layouts, новые поля Joomla Form для тарифов и обновлённые js виджета CDEK.
документация библиотеки. Все методы библиотеки подробно описаны, а так же текст документации собран в отдельной папке в git репозитории.
Пример запроса — запрос информации о городе.
<?php use Webtolk\Cdekapi\Cdek; \defined('_JEXEC') or die; // Вариант 1: брать credentials из настроек плагина $cdek = new Cdek(); // Вариант 2: передать credentials явно $cdek = new Cdek(test_mode: true, client_id: 'your_client_id', client_secret: 'your_client_secret'); $result = $cdek->location()->getCities([ 'postal_code' => '410012', 'city' => 'Саратов', 'size' => 1, ]);
Результат запроса:
Array ( [0] => Array ( [code] => 428 [city_uuid] => 7e54a0b3-76f0-41e2-92e0-f1e600ad84fd [city] => Саратов [fias_guid] => bf465fda-7834-47d5-986b-ccdb584a85a6 [country_code] => RU [country] => Россия [region] => Саратовская область [region_code] => 47 [fias_region_guid] => df594e0e-a935-4664-9d26-0bae13f904fe [sub_region] => городской округ Саратов [longitude] => 46.034266 [latitude] => 51.533562 [time_zone] => Europe/Saratov [payment_limit] => -1 ) )
Библиотека эта нужна для разработчиков, создающих свои расширения для интеграции Joomla и курьерской службы CDEK.
Собрал форк Backbone.js без jQuery, Underscore.
Typescript, ES module, поддержка классов
https://ostovjs.org/
https://github.com/DmitryOlkhovoi/Ostov
Два факта об int в Python
Один забавный факт привел меня к открытию другого :)
Читал Fluent Python и наткнулся на пример кода, который меня заинтересовал (помимо миллиона других, книга – топ). В главе про конкурентность и работу GIL была константа NUMBERS с необычным значением:
NUMBERS = 5_000_111_000_222_021
Нижние подчеркивания
Если не встречали в работе или документации, то вряд ли знаете (как и я): в числах можно использовать _ для читаемости. Интерпретатор их игнорирует:
>>> x = 1_2 >>> y = 12 >>> x == y True >>> x is y True
Особенно удобно в высокоразрядных числах. Согласитесь 5_000_111_000_222_021 куда проще читать, чем 5000111000222021
Кеш малых чисел
Примеры ниже разбирал на домашнем ноуте с Cpython 3.13.11 и 3.14.3.
Пока игрался, меня заинтересовал один прикол. Я попробовал тот же пример с большими числами:
>>> x = 100_500 >>> y = 100500 >>> x == y True >>> x is y False # Но ведь в примере выше было True..
Почему переменные больше не ссылаются на один объект?
В Cpython есть кеш для маленьких чисел, чтобы частые значения переменных не занимали много памяти и код был отзывчивее.
Ответ на вопрос: «где граница, до которой числа закешированы?» я решил не гуглить, проверил небольшим скриптом:
>>> x = 0 >>> y = 0 >>> for n in range(1000): ... print(f'If {x=} and {y=}, x is y: {x is y}') ... x += 1 ... y += 1 # Пропустим часть строк If x=254 and y=254, x is y: True If x=255 and y=255, x is y: True If x=256 and y=256, x is y: True If x=257 and y=257, x is y: False # Вот и граница If x=258 and y=258, x is y: False ...
Сначала я сделал эмпирически вывод, что закеширован диапазон 0 – 256. Но после самопроверки с гуглом узнал, что также в амортизированный диапазон входят числа от -5 до -1. Итого : от -5 до 256 включительно.
UPD 15.03.2026. Добрый дядя в комментах принес ссылку на pr в Cpython 3.15, где кеш малых чисел увеличен до 1024 :). Ух, заживем..
Для присвоения переменным чисел вне диапазона, интерпретатор начнет выделять уже раздельные области памяти и is станет возвращать False.
Так то. В оптимизации пригодится вряд ли, но удивить друзей в баре сможете.
Учимся писать промпты правильно
Я когда начинал погружаться в агентскую разработку, постоянно испытывал легкое чувство стыда, за то, что делаю все как колхозник, а не как "настоящий инженер", который значит продумал задачу, разложил на шаги, обсудил с ии, дальше итеративно, задав кучу условий и ограничений начал реализовывать.
Мой подход "надо сделать вот это" и дальше уже куда поведет его и куда поведет меня. И это действительно было проблемой, когда я работал в агентах без режима планирования. Доходило до смешного, ты хотел с ним поговорить, он начинает херачить, ты ему "стоять нахер", он там уже наломал дров. В итоге постоянно откатывался сам либо просил откатывать его. В целом, это тоже хороший опыт, понимания того как вообще такие системы работают, где у них границы, как лучше формулировать и так далее.
Но в любом случае, даже это не приучило меня как-то сидеть и расписывать, потому что ты никогда точно не знаешь, куда поведет агента на чем он запнется. Тебе мерещится одно, а он начинает тупить ваще в неожиданном месте.
А потом появился режим планирования. И в этот момент, все эти обучалки и принципы того как надо заранее хорошо подумать над задачей превратились в тыкву. Даже если вы начинаете мычать что-то в терминале, современные агенты сами направят, сами зададут вопросы и подсветят важные моменты. Главное в целом понимать что вам нужно и каким будет финальный результат. В этот момент мне перестало быть стыдно.
Вдруг меня осенило, слишком сильное обдумывание до начала работы в агентской разработке (последние полгода), стало чем-то сродни преждевременной оптимизации. Поработав с большим числом моделей и агентов, могу сказать, что если вы будете сами все продумывать, то заставите работать более менее нормально даже самые тупые модели, но вы никогда не поймете границы их возможностей, где они могут еще больше взять на себя освободив вас от рутины. А модели и агенты постоянно развиваются, там где раньше надо было подсказывать, теперь они могут сами. Плюс если вы работаете над AGENTS.md, скилами и mcp, то и тут мы ловим буст.
Поэтому сейчас я иду по такому пути. Включаю режим планирования и дальше даю короткое описание задачи и подробный контекст.
Для упавшего ci это выглядит так:
Поправь тесты
Прошу посмотреть последний запущенный билд на github actions
Баг в браузере:
прошу открыть страницу (он это делает через mcp chrome) и самому изучить
Для рефакторинга:
Переводим вот это на это
Вот эталон (тут ссылка на файл)
Для фичи:
Нужно реализовать такую фичу
Даю пример или говорю с помощью какого инструмента
И все. Самые продвинутые модели типа opus 4.6 или codex 5.3 справятся самостоятельно с большинством острых углов. Сами спросят объем, посмотрят разные варианты, изучат доку и так далее. Модели по тупее, не сделают глубокого анализа и ничего особо не спросят, но именно тут вы поймете где их надо вести и включать свой мозг чаще. Хотя хорошие модели настолько сильно помогают, что я физически не могу использовать более простые для задач планирования. Они хороши в авторежиме только для работы по аналогии, рефакторинг, написание тестов и так далее.
Даже если вы что-то забудете или пропустите сразу, все это можно будет доуточнить, попросить показать примеры кода, сходить открыть браузер. Если в процессе появляются вещи, которые агент делает из раза в раз, например, пытается выяснить где что-то лежит, как работать с какой-то частью системы, то постепенно это выносится в AGENTS.md и с определенного размера и уровни сложности (когда уже нужны скрипты например и команды) выносится в skill.
А зачем покупаете WAF, который можно обойти?
С таким вопросом разработчиков периодически сталкиваюсь. Добавлю контекста. Работаю AppSec инженером в финтехе. Когда нахожу уязвимости — сообщаю разработчикам. Среди прочего - доношу мысль: если в данном случае можно смягчить потеницальные последствия угрозы через WAF — это не значит, что уязвимость не нужно исправлять в приложении. Нередко разработчики спорят. Примерный диалог:
— Ну, есть же WAF — на нём и делайте фикс, зачем нам-то в код лезть? WAF — он же для того и нужен, чтоб уязвимости устранять.
— WAF — не панацея: на нём мы сделаем правило. Но это не значит, что в самом приложении не нужно устранять.
— Почему?
— Например, потому, что практически любой WAF можно обойти.
— А зачем покупаете WAF, который можно обойти?
Отвечаю так: потому что WAF пишут такие же разработчики, как Вы, и они тоже иногда ошибаются (как и все люди). Некоторые особо настырные разработчики желают доказательств, что WAF можно обойти. В целом я солидарен, что практика "а ты докажи" в управлении уязвимостями - не очень хороша. Но, если есть под рукой на что можно быстро сослаться - можно это сделать. Я ссылаюсь на эту статью.
В моей практике были случаи, когда WAF из-за сбоя переставал применять правила на несколько дней. Т.е. трафик через него шёл, сервис за WAF продолжал быть доступным. Но, правила на WAF не работали — будто их и нет.
Эта история в очередной раз показывает: насколько бывают различны в оценке ситуации разработчики и "безопасники". Более интересный вариант — когда разработчики считают, что только они могут решать: что является уязвимостью, а что — нет (подробнее об этом я писал в статье "Как я зарегистрировал CVE и разозлил вендора").
Экономия памяти со __slots__
В Python атрибуты классов по-умолчанию хранятся в специальном dunder-атрибуте __dict__. В описании класса его задавать не надо, он есть неявно и доступен для просмотра при необходимости. Каждый экземпляр класса также имеет свой __dict__:
class Standard: def __init__(self, x, y): self.x = x self.y = y std = Standard(100, 200) std.__dict__ # {'x': 100, 'y': 200}
Помимо того, что и класс и экземпляры отдельно занимают своими __dict__ место в памяти, хранение данных в словарях само по себе несет большие накладные расходы. Хеш-таблица в основе словаря хранит служебные структуры и растёт скачками при увеличении числа атрибутов, поэтому на больших количествах объектов затраты памяти ощутимы:
from sys import getsizeof std_size = getsizeof(std) + getsizeof(std.__dict__) std_size # 344 байта
Один из эффективных способов сэкономить память, это реализовать в классе специальный атрибут __slots__ и объявить в нем последовательность атрибутов экземпляра. Тогда вместо __dict__, Python будет использовать альтернативную структуру хранения атрибутов с помощью дескрипторов. __slots__ для экземпляров классов отдельно не создается и хранится только на уровне класса:
class Slot: __slots__ = ('x', 'y') # Неизменный кортеж из имен атрибутов def __init__(self, x, y): # Остальное – без изменений self.x = x self.y = y slt = Slot(100, 200) slt.__dict__ # **AttributeError**: 'Slot' object has no attribute '__dict__'. Did you mean: '__dir__'? slt_size = getsizeof(slt) slt_size # 48 байтов
Так добавив одну строчку кода, можно сэкономить расходы памяти в приложении, где требуется создавать миллионы одинаковых объектов.
---
Важные ограничения
Стоит отметить, что реализация __slots__ запрещает динамически добавлять экземпляру класса атрибуты, в отличие от __dict__. В ситуациях, где такое необходимо, __slots__ не подойдет.
std.z = 300 std.__dict__ # {'x': 100, 'y': 200, 'z': 300} slt.z = 300 # **AttributeError**: 'Slot' object has no attribute 'z' and no __dict__ for setting new attributes
Важно, не забывать расширять слоты, если мы добавляем в код класса новые атрибуты:
class PartialSlots: __slots__ = ('x', 'y') # Не добавили атрибут экземпляра 'z' def __init__(self, x, y, z): self.x = x self.y = y self.z = z p = PartialSlots(100, 200, 300) # **AttributeError**: 'PartialSlots' object has no attribute 'z' and no __dict__ for setting new attributes
В подклассах от класса со __slots__ наследование этого атрибута проходит лишь частично. Для полноценного использования, его стоит определить еще раз, включив новые атрибуты подкласса:
# Подкласс без доп. логики class InheritSlot(Slot): pass inh_slt = InheritSlot(100, 200) inh_slt.__dict__ # {}, атрибут снова доступен inh_slt.z = 300 # Нет ошибок при динамическом расширении атрибутов inh_slt.__dict__ # {'z': 300}, словарь подкласса снова занимает память # Поправим class InheritSlot(Slot): __slots__ = ('z', ) # Слоты суперкласса добавятся в начало кортежа. В конце не забываем запятую, так как это кортеж из одного элемента. inh_slt2 = InheritSlot(100, 200, 300) inh_slt2.__dict__ # AttributeError ... теперь слоты используются корректно в подклассе
Команда проекта Pencil.dev обновила сервис и теперь он генерит любые интерфейсы по клику. В решение внедрили режим «Рой», который создаёт сразу несколько вариаций вашего проекта с помощью шести ИИ‑агентов параллельно. Можно грузить любые файлы и даже кастомные шрифты. Проект поддерживает Antigravity, Copilot, Gemini CLI, Opus 4.6, Sonnet 4.6 и даже OpenCode. Результат можно экспортировать во всех самых популярных форматах: PDF, JPG, PNG и WebP. Также стало доступно полноценное приложение для Windows.
Особенность Joomla: json-значения для пользовательских полей и их рендер в subform и вне дочерней формы.
Опять длинное название, но куда уж без этого...
Итак, если вы делаете плагин пользовательского поля - его можно использовать через FieldsHelper. И в процессе ваши данные проходят через различные этапы обработки (недавно была статья на эту тему). И может так оказаться, что ваше поле хранит в rawvalue json (и в базе данных соответственно тоже), а в value вы на его основе рендерите значение. Это стандартный подход Joomla. Так работают, например, поля accessiblemedia. Однако, если вы поместили ваше поле в дочернюю форму (пользовательское поле типа subform и включили "Рендеринг значений = Да", то у вашего замечательного поля может появиться поломанный Json в value вместо нормального значения.
Например:
{"basePath":"...","layout":"..."}
❓ Что там под капотом Joomla происходит?
В обычном потоке Joomla сначала вызывает событие onCustomFieldsBeforePrepareField, а потом onCustomFieldsPrepareField.
Внутри subform же для подполей при render_values=1 вызывается только событие - onCustomFieldsPrepareField.
Если преобразование значения (например, json_decode) сделано в вашем плагине только в beforePrepareField, оно не обработает данные для подполя и...
В шаблоне поля строка заэкранируется (htmlentities), кавычки превратятся в тыкву в " и вы получите кривой json, вместо вашего значения.
👉 Собственно полезный совет по Joomla:
Для полей, которые могут жить внутри subform, делайте нормализацию значения и в onCustomFieldsPrepareField тоже, не только в beforePrepareField.
Фронтенд 2026: взлеты и падения
Открываешь проект 2020 года и видишь знакомые имена в package.json: create-react-app, enzyme, moment.js, axios. Пять лет назад это был золотой стандарт. Сегодня же эти технологии вызывают у коллег искреннее недоумение: «Зачем это тут?»
Подготовили для вас быстрый, но очень полезный срез того, как за 5 лет поменялась ментальная модель фронтендера. Внутри инструменты реально умерли, разберемся почему SSR/SSG снова в игре, а TypeScript теперь почти must-have, узнаем почему фронтенд всё чаще = full-stack и что с этим делать.
Главный урок 2015→2025: фронтенд развивается циклически. Каждый цикл — это не «прогресс», а перебалансировка компромиссов. Читайте на Хабр в статье «Фронтенд 2026: что умерло, что выжило и что взлетело неожиданно»
Как понять, что ваш интернет-магазин вот-вот сломается: триггеры и решения для сайтов на Magento
Привет! Это Дмитрий Абакумов magento-разработчик в Далее, и Максим Бровко, тимлид в Далее.
Мы собрали 5 типичных симптомов, которые сигнализируют, что система уже нестабильна — на примере Magento, популярной CMS в сфере e-com.
В первую очередь скажем, что на Magento работают крупные бренды по всему миру. Она гибкая, масштабируемая, с богатой экосистемой. Однако без регулярных обновлений, контроля и DevOps-поддержки любой проект начинает замедляться, сбоить, а со временем — ломаться. Сигналы появляются заранее: сначала падает скорость, потом checkout, потом весь сайт.
Сигнал 1: падение скорости при большом трафике — во время акций и распродаж
Что проверить
Узкие места в БД: тяжелые SELECT, отсутствие индексов.
Дублирующиеся или вложенные вызовы блоков в Magento layout.
Как ведет себя cron и очередь задач.
Используется ли Varnish для FPC и/или Redis для общего кеша.
Как чинить
Настроить загрузку тяжелых блоков после рендера страницы — через AJAX.
Внедрить нагрузочное тестирование — k6, Siege, JMeter.
Перенастроить кеш Magento, включить компиляцию DI.
Заложить горизонтальное масштабирование или CDN.
Сигнал 2: долгая загрузка интернет-магазина при обычной посещаемости (более 3 секунд)
Что проверить
Логи Magento и серверов: timeouts, ошибки, блокировки.
Скорость отклика API.
Время сборки layout и количество подключаемых блоков.
Как чинить
Проанализировать профилировку — Xdebug, New Relic.
Отключить неиспользуемые плагины и модули.
Настроить мониторинг производительности и ошибок — New Relic, Grafana, Prometheus.
Сигнал 3: Клиенты доходят до оформления, но не покупают — особенно на мобильных устройствах
Что проверить
Как работает checkout: отрисовка, JS, блоки, сторонние виджеты доставки/оплаты.
Как отрабатывает кнопка «Оформить заказ» — все ли проходит быстро.
Нет ли тяжелых или повторяющихся вызовов.
Как чинить
Кешировать доступные блоки внутри checkout.
Упростить форму и ускорить ввод данных — DaData.
Включить асинхронную обработку заказов, если оформление занимает много времени.
Протестировать на реальных устройствах и подключить фронтовый логгер — Sentry.
Сигнал 4: когда починили один баг — появился другой
Что проверить
Архитектуру модулей: tight coupling, перезапись классов, обилие around-плагинов.
Есть ли автотесты, CI.
Как внедряются хотфиксы.
Как чинить
Минимизировать around-плагины и preference (перезаписей классов), отдавать предпочтение before/after-плагинам и observer.
Покрывать фиксы хотя бы базовыми unit/integration-тестами.
Настроить dev → stage → prod, релизный процесс с changelog.
Ввести code style, практику ревью и договоренности внутри команды.
Сигнал 5: CMS или модули устарели, все «на костылях» и никто не решается трогать
Что проверить
Версии ядра Magento и зависимостей.
Нет ли deprecated-библиотек, особенно JS.
Насколько кастомно переопределены шаблоны и классы.
Есть ли onboarding-документация, описание архитектуры, миграций, cron.
Как чинить
Если кастомный код внесен прямо в ядро Magento, то его нужно вынести в отдельные модули.
Сравнить архитектуру с best practices Magento и рекомендациями вендоров.
Написать README и настроить автоматизацию — Docker, Ansible.
Запланировать регулярные апдейты проекта.
Если у вас совпадают 3+ пункта — пора на техаудит
Magento почти всегда подает сигналы заранее: снижается скорость, растет количество багов, страдает checkout. Если таких симптомов становится много — пора остановиться и разобраться, что происходит внутри.
Что делать
Использовать метрики: PageSpeed, TTFB, логи ошибок.
Провести аудит: кеш, модули, layout, архитектура, DevOps.
Найти узкие места и критичные зависимости.
Выделить приоритеты по улучшениям и составить roadmap по рефакторингу.
Разбираемся как принимать звонки в браузере. Основы WebRTC\SIP\RTP.
Во многих коммуникационных продуктах возникает потребность работы с голосом. В этой серии постов разберемся как организовать прием звонков непосредственно из вашего web приложения. Какие есть варианты передачи звукового потока и какая может быть архитектура backend приложения, обеспечивающего его работу.
Начнем с самой простой в реализации схемы, в которой передача голоса осуществляется напрямую между браузером пользователя, открывшего ваше web приложение и серверами провайдера "виртуальной телефонии"(aka "виртуальная атс" ).
При этом вся мета информация о поступившем входящем звонке и событиях всего жизненного цикла звонка принимает ваш backend. У разных провайдеров телефонии набор событий и строения api может отличаться, но общая схема работы схожа.
Разберем основную схему организации передачи голоса. Браузер по сути работает как SIP‑телефон: сигнализация через WebSocket, медиа — по RTP.
1. Регистрация в сети
Оператор открывает страницу в браузере.
Браузер отправляет SIP REGISTER на SIP‑сервер (WebSocket/TLS).
SIP‑сервер отвечает 200 OK.
В интерфейсе показывается «Вы в сети» — оператор готов к звонкам.
2. Звонок
SIP‑сервер отправляет SIP INVITE в браузер.
Браузер показывает уведомление «Входящий».
Оператор нажимает «Принять».
Браузер запрашивает доступ к микрофону (getUserMedia) — внутреннее действие.
Браузер отправляет SIP 200 OK + SDP на SIP‑сервер.
SIP‑сервер отправляет SIP ACK в браузер.
SIP‑сервер даёт команду RTP/SRTP‑шлюзу установить медиа‑сессию.
Медиа (RTP/SRTP по UDP) передаётся между браузером и RTP‑шлюзом.
Начинается разговор.
3. Завершение звонка
Оператор нажимает «Завершить».
Браузер отправляет SIP BYE на SIP‑сервер.
SIP‑сервер отвечает 200 OK.
Передача RTP/SRTP прекращается.
Если тема будет интересна, то далее обсудим схему работы backend'а и варианты развития общей схемы передачи голоса с плюсами, минусами и ограничениями.
В своем канале в Telegram и канале в Max о разработке в стартапах рассказываю еще больше интересного и делюсь опытом, заходите, буду рад!
Спокойных вам релизов и захватывающих решений !
В чём подвох пожизненной гарантии на сайт
Просматривая сайты коллег по опасному бизнесу сайтостроения иногда натыкаюсь на термин «пожизненная гарантия на сайт» и становится дико смешно от этого.
Вообще, сайт сам по себе не ломается. Это или баг, который не нашли при разработке, или влияние внешних сил:
Поменялось API у системы, с которой сайт интегрирован. Гугл почта включила режим паранойя, ЯндексКарты формат запроса, чат гопоты стал хотеть другой прокси-сервер.
И сайт уже работает не так, как задумывалось.
Мамкины хакеры поломали. Если во-время обновлять версии безопасности, сайты вполне могут страдать.
Полозушные руки чужих разработчиков ковырялись в коде. Если нет резервных копий или нельзя откатиться по версиям — это печаль.
Проблема с сервером. Закончилось место на диске, не хватает вычислительной мощности, набежали боты, DDoS-атака
Некорректное отображение в версиях браузеров, вышедших после создания сайта. Это бывает редко, однако возможно, что сайт по прошествии нескольких лет может перестать правильно отображаться в браузерах. Браузеры (Гугл Хром, Опера и другие) постоянно совершенствуются, меняются, перестают поддерживать какие-то устаревшие функции и стандарты.
И это всё гарантию никто не включает. Оно и понятно. Предсказать их влияние невозможно, а чинить проблему может быть трудозатратно.
А «пожизненная гарантия» распространяется только на случай, если в процессе эксплуатации сайта будут выявлены ошибки, связанные с разработкой, компания бесплатно исправит их.
ИТОГО. Пожизненная гарантия — полная туфта.
Не играйте в эти игры. Лучше честно сделать договор на техподдержку, где указаны форсмажоры.
Мой тг-канал — Факапы, инсайты, проблемы, взаимоотношения, клиенты, немного юмора.
Спустя почти год работы мой PR приняли в ядро Joomla!
[Тут должна быть победная пляска] Год назад у моих клиентов возникла необходимость во вставке видео в кастомные поля материалов в раздел портфолио. Я начал делать и увидел, что именно стандартное пользовательское поле Media не умеет вставлять в поле ничего, кроме изображений, хотя поле Joomla Form MediaField умеет выбирать и документы (pdf и иже), аудио, видео и даже папки. Я начал работу над тем, чтобы добавить этот функционал в ядро и очень надеялся успеть к Joomla 5.3, которая выходила в апреле. В целом все сделал, сделал PR 25 февраля 2025 года, но PR не приняли, сказав, что это шибко новый функционал и ему будет хорошо в Joomla 6.0.0. Клиентам пришлось использовать медиа-менеджер от JCE, а PR отправился ждать релиза 6.0.0, который выходил осенью. К слову сказать, эта пауза была полезна для него, так как летом, уже неспешно я получал советы по улучшению и в июле всё точно было готово.
Релизный цикл Joomla состоит из нескольких этапов: сначала выходят alpha-версии (до 3х штук), где просто фиксируются накопленные изменения, потом beta, где наступает feature freeze - заморозка новых функций, их нельзя уже добавлять. Дальше только отладка и правки существующих новшеств. У каждого релиза есть 2 релиз-менеджера.
В работе над PR мне помогал все это время Брайан Тиман - ко-фаундер Joomla. К концу июля все было готово, проверено, PR имел 2 необходимых независимых теста. Ждём беты.
Дата беты приходилась на понедельник. Где-то в пятницу днём я отписался в PR и получил совет написать релиз+менеджерам. Как-то удалось найти их в Mattermost, где обитает международное сообщество, но пятница и выходные, а все ж волонтеры и не на зарплате... Моё сообщение прочитали после релиза беты... Сказали, что не были в курсе моего PR (ожидаемо, их около 200-250 все время открытых). И сказали, что поезд ушёл, хоть и so sorry. Зато будет хорошо увидеть PR на тестах в Pizza, Bugz and Fun и вообще welcome в 6.1.
После выхода 6.0.0 меняются релиз-менеджеры. Мы списались: да, все хорошо, но нужно кое-что подправить. Тут конец года и закрытие дедлайнов, потом Новый год и весь январь никто толком не работает. Beta для 6.1 выходит 17 февраля. Последняя alpha недели за 3 до этого.
Незадолго до выхода альфы я-таки получаю сообщение, что реализуемый функционал сделан не по "Joomla way" и если код в ядре, то этот код является учебным пособием по тому, как ядро использовать. Резонно. А ещё у релиз-менеджера есть собственные наработки и экспертиза в этой теме и свой медиа-менеджер, в котором он тоже прошел огонь, воду и медные трубы. Согласно Joomla way мне нужно было разделить одно мега-крутое поле на 4 отдельных (картинки, аудио, видео и документы). Я подумал, что требуется сделать 4 плагина вместо одного и сказал, что не успею. Мне ответили, что beta is more important for us и время ещё есть, что мне подскажут и 4 плагина делать не нужно.
Пока суть да дело - время идёт. У меня тоже работа, трое детей, карантины, уроки... Но добить этот PR уже стало делом принципа. Я нашел как нужно было делать, принял несколько правок и пожеланий, потом фиксы code style. Сегодня с утра был последний коммит. Сегодня вечером, 11 февраля 2026 года, PR наконец-то смержен в ядро Joomla.
Эта работа научила меня очень многому. 170 комментариев в conversation на GitHub, несколько отдельных переписок, 1 год на разработку и внедрение простой в целом фичи, "звоночек" в голове: "не забыть, успеть, сделать, найти"...
Сегодня я поднимаю кружку пенного за этот небольшой в целом PR, за этот прошедший год, за Joomla и за Open Source.
https://github.com/joomla/joomla-cms/pull/45013
#joomla #cms #opensource #community #webdev
P.S. Фото с пивом сюда выставлять не буду, но представьте, что оно тут есть.
ИИ в техподдержке SpaceWeb решает каждый четвертый запрос
В SpaceWeb ИИ-ассистент стал полноценным инструментом для работы с запросами веб-разработчиков. Сегодня нейросеть полностью закрывает 23,5% обращений пользователей, а ещё в 64% случаев помогает специалистам поддержки формировать ответы.
ИИ берет на себя типовые задачи, с которыми разработчики сталкиваются при запуске и сопровождении сайтов: подключение доменов и SSL, установка CMS, настройка почты, работа в панели управления. Среднее время ответа — около 30 секунд вместо 10–15 минут у человека. В месяц бот самостоятельно обрабатывает более 1200 запросов.
За счет этого нагрузка на сотрудников поддержки снизилась на 9,5%, а эксперты смогли сосредоточиться на сложных и нестандартных кейсах. Для дообучения модели используется обратная связь от пользователей — ответы ИИ можно оценивать лайками.
Как именно устроена работа ИИ-ассистента, какие сценарии он закрывает уже сейчас и зачем SpaceWeb внедрял нейросеть в поддержку — читайте на сайте.
Представлен открытый проект PeerWeb — децентрализованного веб‑хостинга на базе WebTorrent. Решение обеспечивает децентрализованный, устойчивый к цензуре веб‑хостинг через пиринговые сети. «Загружайте свои статические веб‑сайты и делитесь ими по всему миру, не полагаясь на централизованные серверы и не оплачивая хостинг», — пояснили авторы решения.
Selectel открыл первую часть курса по JavaScript
Привет, Хабр! Новичкам бывает трудно сделать первый шаг в программировании. В интернете много сомнительных курсов, а качественные требуют финансовых вложений и несколько месяцев на изучение.
Мы в Selectel подготовили бесплатный курс, который поможет быстро и без лишних затрат изучить основы JavaScript. В первую часть входят три модуля. Вы узнаете:
для чего разработчики используют JavaScript,
как работать с со скриптами, веб-страницами и переменными,
как создать рабочее окружение на IT-инфраструктуре Selectel.
Участники курса смогут бесплатно протестировать сервисы Selectel, а по итогам тестирования — получить сертификат о прохождении.
Событие Pizza, Bugs & Fun - 29-30 января 2026 года.
Уже несколько лет в мире Joomla проводятся мероприятия "Pizza, Bugs & Fun" (#PBF), где каждый может посвятить несколько часов своего мозгового времени тому, чтобы наша любимая CMS стала ближе к идеалу.
Ссылки на видео и статьи из этого поста рассказывает об организационных вопросах, которые пригодятся для участия в PBF, а так же что и как делать. Координация международного сообщества Joomla происходит в Mattermost (присоединиться).
В рамках события PBF все желающие могут собираться в общий онлайн чат, обсудить вопросы Joomla и приложить к их разрешению свою руку. Самый классный вариант, когда эта встреча происходит оффлайн: тогда организовывается пицца, напитки по вкусу и несколько часов совместного творчества.
Каждый помогает тем, что он умеет:
кто-то пишет недостающую документацию,
кто-то пишет код,
кто-то тестирует как исправлены ошибки или сделан новый функционал.
На сайте события есть карта, можно "захостить" свою локацию. Практически все движки в мире развиваются за счёт спонсирующих их компаний. Joomla одна из немногих, где развитие идёт только усилиями международного сообщества энтузиастов.
На момент написания данного поста в репозитории Joomla 810 открытых Issue (как правило это баги) и 236 Pull request (PR, исправление багов и новый функционал). Все PR обязательно тестируются минимум двумя участниками сообщества, дабы в конечный код движка не проскочила ошибка.
Если каждый из участников только нашего сообщества сделает даже одно тестирование, то, боюсь, PR и Issue на всех не хватит 😀 И ничего не останется нашим коллегам из международных Joomla-чатов.
Как тестировать Joomla PHP-разработчику? Компонент Patch tester. (кстати, не только PHP разработчику)
Пост о наболевшем. Clawd и как же им пользоваться.
В общем два дня уже потратил на то чтобы развернуть Clawd bot, естественно в бесплатном формате, по началу шло все хорошо, развернул бота на локальном компе Linux Mint 22.2, создал бота в Телеграмме, привязал к нему Clawdbot.
Так как у clawd нет своей нейронки, ему нужно прикрутить свои мозги. Сначала запросил API ключ в Gemini. Обычная модель, даже самая простая не запускалась. Затем тыкнул в Google Antigravity, который как оказалось имитирует думающую модель Claude 4.5 пуская один и тот же запрос в себя по кругу. Эта штука быстро отвалилось, но успел немного поразвлекаться с ней.
Перебрал половину представленных в списке Clawd моделей, например тот же Deepseek дает API только разработчикам, но в него можно получить доступ через такие сервисы (из списка Clawd), как Openrouter. Openrouter в свою очередь выдал ключ, но выбирая из списка модели, даже с пометкой free ничего не взлетало. На этом я уже устал если честно, поэтому обращаюсь к хабру, дабы развернуть актуальную дискусиию, может накидаете вариантов решения или альтернатив Clawd, а то уж очень захотелось поиграть в агента.
Успел спросить у него, с мозгом Google Antigravity, что он может:
🔧 Код и файлы
— Читать, писать, редактировать код и документы
— Запускать команды в терминале, работать с git🌐 Интернет
— Искать в вебе, парсить страницы
— Управлять браузером (автоматизация, скрейпинг)📅 Организация
— Напоминания и cron-задачи
— Вести заметки, память между сессиями💬 Коммуникация
— Telegram (вот тут и сидим), можно подключить другие каналы
— Могу отправлять сообщения, реагировать🏠 Умный дом / устройства
— Если подключишь ноды — камеры, уведомления на телефон🤖 Сложные задачи
— Могу запускать саб-агентов на длинные задачи в фонеПо сути — твой персональный ассистент-разработчик, который живёт в терминале и мессенджерах.
И соответсвенно мой список вопросов:
Стоит ли брать платную модель? И какую брать если, уж брать?
Насколько я понимаю штука супер небезопасная, а если запускать из песочницы, то все равно прийдется давать какие-то доступы?
Какие есть альтернативы? Уж очень понравился способ взаимодействия через ТГ
Представлен открытый веб-редактор изображений DPaint.js (онлайн-версия) на JavaScript, созданный по образцу легендарного Deluxe Paint, с упором на ретро-форматы файлов Amiga. Помимо современных форматов изображений, DPaint.js может читать и записывать файлы иконок Amiga и изображения IFF ILBM.
Основные возможности проекта: слои, выделение, маскирование, инструменты трансформации, эффекты и фильтры, множественная отмена/повтор действий, копирование/вставка из любой другой программы обработки изображений или источника изображений, настраиваемые инструменты дизеринга и циклическая смена цветов.
Коллеги привет, искал себе решение как реагировать на изменения в объекте и нашел отличный сервис, который используется внутри директив таких как NgClass и NgStyle.
KeyValueDiffers позволяет создать KeyValueDiffer для сравнения изменений текущих пар ключ-значение с новыми. Если вы используете иммутабельные объекты, то можно просто обернуть все в эффект, ну а если вы наследники крутого легаси, где все объекты мутируются по ссылке, тогда проверку нужно вешать в DoCheck, чтобы реагировать на каждый тик change detection.
Накидал оба примера, чтобы поделиться с вами:
Иммутабельный с effect:
@Component({ selector: 'app-test', template: '' }) export class TestComponent { public state = input.required<Record<string, string | number>>(); private differs = inject(KeyValueDiffers); private differ: KeyValueDiffer<string, string | number> | undefined; constructor() { effect(() => { const currentState = this.state(); // создаем диффер, если он еще не создан if (!this.differ) { this.differ = this.differs.find(currentState).create(); } // Эффект будет перезапускаться при изменении инпут-сигнала. const changes = this.differ.diff(currentState); // только если есть изменения if (changes) { changes.forEachAddedItem((record) => { console.log(`В объект добавлена запись: Ключ: ${record.key} | Значение: ${record.currentValue}`) }); changes.forEachChangedItem((record) => { console.log(`Изменено: ${record.key} | Новое значение: ${record.currentValue}`) }); changes.forEachRemovedItem((record) => { console.log(`Удалено: ${record.key}`) }); // Остальные методы forEachItem и forEachPreviousItem по необходимости } }) } }
Легаси подход, которого, надеюсь, ни у кого нет, но на всякий случай :)
@Component({ selector: 'app-legacy', template: '' }) export class LegacyComponent implements OnInit, DoCheck { @Input({ required: true }) state!: Record<string, string | number>; private differs = inject(KeyValueDiffers); private differ: KeyValueDiffer<string, string | number> | undefined; ngOnInit() { // Создаем диффер при инициализации this.differ = this.differs.find(this.state).create(); } // Запускается на каждый тик change detection, так как мутации по-другому не отследим. ngDoCheck(): void { const changes = this.differ?.diff(this.state); if (changes) { changes.forEachAddedItem((record) => { console.log(`В объект добавлена запись: Ключ: ${record.key} | Значение: ${record.currentValue}`) }); changes.forEachChangedItem((record) => { console.log(`Значение изменилось: ${record.key}`) }); changes.forEachRemovedItem((record) => { console.log(`Запись удалена: ${record.key}`) }); // Остальные методы forEachItem и forEachPreviousItem по необходимости } } }
Онлайн сервис проверки конфига nginx на безопасность (Gixy-Next)
На Хабре уже упоминался Gixy как средство проверки безопасности\хардеринга nginx (статья раз, статья два). Недавно появился ещё один проект, основанный на форке Gixy: Gixy-Next (репозиторий, сайт проекта). Из интересного: прямо на сайте есть возможность проверить конфиг nginx (если по какой-то причине не хочется устанавливать приложение). В тексте найденных проблем - ссылки на страницы с подробным описанием типа ошибки.
Решил сегодня почитать, что пишут в Ангуляр комьюнити Хабра, и увидел сильно популярный пост с аж 51 лайком и 71 закладкой.
Начал читать и был удивлен примерами. Автор с уверенностью говорит, как писать на Ангуляр грамотно, и при этом приводит плохие практики в качестве примеров. Я дошел до примера с RxJS, который меня немного триггернул.
Не буду разбирать все кейсы указанные в данном посте, покажу лишь самый плохой пример который меня немного тригернул:
Автор условно говорит, что у нас есть плохой пример использования:
this.http.get('/api/data').subscribe((data) =>; { this.data = data; // Что если запрос не вернётся? });
и затем приводит хороший пример с сигналами и RxJs:
readonly data = signal([]); readonly error = signal(null); loadData() { this.http.get('/api/data').pipe( tap(() =>; this.error.set(null)), // Сбрасываем предыдущую ошибку перед загрузкой catchError((err) =>; { this.error.set('Не удалось загрузить данные'); return of([]); // Возвращаем пустой массив, чтобы поток не прерывался }) ).subscribe((result) =>; { this.data.set(result); }); }
я даже не буду указывать на количество антипатернов и плохих практик в данном примере, я просто покажу правильный пример с сигналами и RxJs:
interface State<T = object> { data: T[]; error: string | null; } @Component({...}) export class BestRxJs { private http = inject(HttpClient); private loadDataAction$ = new Subject<void>(); private state$ = this.loadDataAction$.pipe( switchMap(() => this.http.get<State[]>('/api/data').pipe( map((result) => ({ data: result, error: null })), catchError(() => of({ data: [], error: 'Не удалось загрузить данные' })), startWith({ data: [], error: null }) ) ), shareReplay({ bufferSize: 1, refCount: true }) ); readonly private state = toSignal(this.state$, { initialValue: { data: [], error: null } }); readonly protected data = computed(() => this.state().data); readonly protected error = computed(() => this.state().error); protected loadData(): void { this.loadDataAction$.next(); } }
Этот пост для новичков, которые, начитавшись популярных статей, могут начать применять вредные практики.
Почему стоит использовать protected в Angular компонентах?
Если вы используете в своих компонентах только public и private, вы упускаете возможность сделать архитектуру чище. Я предлагаю четко разделять ответственность членов класса.
Часто мы по инерции делаем public любые методы и свойства, которые нужны в шаблоне (HTML). Но public в TypeScript означает, что это публичный API компонента - к этим методам может получить доступ любой родительский компонент через @ViewChild.
Почему стоит использовать protected:
1. Явное намерение: protected сигнализирует, что метод предназначен для использования внутри класса или в его шаблоне, но не должен вызываться извне.
2. Защита от регрессии: Если другой разработчик попытается вызвать такой метод через @ViewChild, TypeScript выдаст ошибку. Это заставит его задуматься: «Действительно ли мне нужно делать этот метод публичным?» или «Может, стоит создать отдельный метод для API?».
3. Читаемость: Открывая код, вы сразу видите: public - для внешнего мира, protected - для шаблона, private - для внутренней логики сервисов и подписок.
Разделяйте Public API и внутреннюю логику шаблона - ваш код станет надежнее и понятнее.
@Component({ selector: 'app-user-profile', template: ` <!-- В шаблоне мы без проблем обращаемся к protected свойствам --> <div class="card"> <h3>{{ userName() }}</h3> <button (click)="onUpdateClick()">Обновить</button> @if(isLoading()) { <div>Загрузка...</div> } </div> ` }) export class UserProfileComponent { // PRIVATE: Внутренняя логика. // Не доступно ни в шаблоне, ни родительскому компоненту. private _userId = 123; // PROTECTED: Доступно только внутри класса и в ШАБЛОНЕ. // Идеально для переменных состояния UI и обработчиков событий. protected userName = signal('Алексей'); protected isLoading = signal(false); protected onUpdateClick(): void { this.logAction(); console.log('Кнопку нажали в шаблоне'); } // PUBLIC: Публичный API компонента. // Только эти методы мы разрешаем вызывать родительскому компоненту. public resetState(): void { this.userName.set('Гость'); this.isLoading.set(false); } private logAction(): void { console.log(`Action logged for userId: ${this._userId}`); } }
Представлен открытый проект на Python под названием Reverse API engineer. Это консольный инструмент, который фиксирует трафик браузера и автоматически генерирует готовые к работе клиенты Python API. Больше никакого ручного реверс‑инжиниринга — просто просматривайте, записывайте и получайте чистый API‑код.
«Этот инструмент выполняет код локально, используя Claude Code‑ пожалуйста, следите за выводом/ На некоторых веб‑сайтах используется расширенная система обнаружения ботов, которая может ограничивать захват или требовать ручного взаимодействия», — пояснил автор проекта.
Особенности Reverse API:
автоматизация браузера: создан на базе Playground с режимом скрытности для реалистичного просмотра;
режим автономного агента: полностью автоматизированное взаимодействие с браузером с помощью агентов искусственного интеллекта (автоматический режим с MCP, использование браузера, stagehand);
запись HAR: фиксирует весь сетевой трафик в архивном формате HTTP;
генерация на основе искусственного интеллекта: использует Claude 4.5 для анализа трафика и генерации чистого кода на Python;
поддержка нескольких SDK: встроенная интеграция с Claude и OpenCode SDK;
интерактивный интерфейс командной строки: минималистичный интерфейс терминала с переключением режимов (Shift+Tab);
готовность к работе: сгенерированные скрипты содержат обработку ошибок, подсказки по вводу текста и документацию;
история сеансов: все запуски сохраняются локально с полными журналами сообщений;
отслеживание затрат: подробное использование токенов и оценка затрат с поддержкой кэширования.
Как тестировать Joomla PHP-разработчику? Компонент Patch tester.
Joomla - open source PHP-фреймворк с готовой админкой. Его основная разработка ведётся на GitHub. Для того, чтобы международному сообществу разработчиков было удобнее тестировать Pull Requests был создан компонент Patch Tester, который позволяет "накатить" на текущую установку Joomla именно те изменения, которые необходимо протестировать.
На стороне инфраструктуры Joomla для каждого PR собираются готовые пакеты, в которых находится ядро + предложенные изменения. В каждом PR обычно находятся инструкции по тестированию: куда зайти, что нажать, ожидаемый результат. Тестировщики могут предположить дополнительные сценарии, исходя из своего опыта и найти баги, о которых сообщить разработчику. Или не найти, и тогда улучшение или исправление ошибки быстрее войдёт в ядро Joomla.
Напомню, что для того, чтобы PR вошёл в ядро Joomla нужны минимум 2 положительных теста от 2 участников сообщества, кроме автора.
Это видео также на:
Чат русскоязычного Joomla-сообщества
#joomla #php #webdev #community
