Обновить
512K+

Веб-разработка *

Делаем веб лучше

298,51
Рейтинг
Сначала показывать
Порог рейтинга

Два факта об 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.

Так то. В оптимизации пригодится вряд ли, но удивить друзей в баре сможете.

Теги:
Всего голосов 11: ↑10 и ↓1+9
Комментарии15

Учимся писать промпты правильно

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

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

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

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

Вдруг меня осенило, слишком сильное обдумывание до начала работы в агентской разработке (последние полгода), стало чем-то сродни преждевременной оптимизации. Поработав с большим числом моделей и агентов, могу сказать, что если вы будете сами все продумывать, то заставите работать более менее нормально даже самые тупые модели, но вы никогда не поймете границы их возможностей, где они могут еще больше взять на себя освободив вас от рутины. А модели и агенты постоянно развиваются, там где раньше надо было подсказывать, теперь они могут сами. Плюс если вы работаете над AGENTS.md, скилами и mcp, то и тут мы ловим буст.

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

Для упавшего ci это выглядит так:

  1. Поправь тесты

  2. Прошу посмотреть последний запущенный билд на github actions

Баг в браузере:

  1. прошу открыть страницу (он это делает через mcp chrome) и самому изучить

Для рефакторинга:

  1. Переводим вот это на это

  2. Вот эталон (тут ссылка на файл)

Для фичи:

  1. Нужно реализовать такую фичу

  2. Даю пример или говорю с помощью какого инструмента

И все. Самые продвинутые модели типа opus 4.6 или codex 5.3 справятся самостоятельно с большинством острых углов. Сами спросят объем, посмотрят разные варианты, изучат доку и так далее. Модели по тупее, не сделают глубокого анализа и ничего особо не спросят, но именно тут вы поймете где их надо вести и включать свой мозг чаще. Хотя хорошие модели настолько сильно помогают, что я физически не могу использовать более простые для задач планирования. Они хороши в авторежиме только для работы по аналогии, рефакторинг, написание тестов и так далее.

Даже если вы что-то забудете или пропустите сразу, все это можно будет доуточнить, попросить показать примеры кода, сходить открыть браузер. Если в процессе появляются вещи, которые агент делает из раза в раз, например, пытается выяснить где что-то лежит, как работать с какой-то частью системы, то постепенно это выносится в AGENTS.md и с определенного размера и уровни сложности (когда уже нужны скрипты например и команды) выносится в skill.

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

А зачем покупаете WAF, который можно обойти?

С таким вопросом разработчиков периодически сталкиваюсь. Добавлю контекста. Работаю AppSec инженером в финтехе. Когда нахожу уязвимости — сообщаю разработчикам. Среди прочего - доношу мысль: если в данном случае можно смягчить потеницальные последствия угрозы через WAF — это не значит, что уязвимость не нужно исправлять в приложении. Нередко разработчики спорят. Примерный диалог:

— Ну, есть же WAF — на нём и делайте фикс, зачем нам-то в код лезть? WAF — он же для того и нужен, чтоб уязвимости устранять.
— WAF — не панацея: на нём мы сделаем правило. Но это не значит, что в самом приложении не нужно устранять.
— Почему?
— Например, потому, что практически любой WAF можно обойти.
А зачем покупаете WAF, который можно обойти?

Отвечаю так: потому что WAF пишут такие же разработчики, как Вы, и они тоже иногда ошибаются (как и все люди). Некоторые особо настырные разработчики желают доказательств, что WAF можно обойти. В целом я солидарен, что практика "а ты докажи" в управлении уязвимостями - не очень хороша. Но, если есть под рукой на что можно быстро сослаться - можно это сделать. Я ссылаюсь на эту статью.
В моей практике были случаи, когда WAF из-за сбоя переставал применять правила на несколько дней. Т.е. трафик через него шёл, сервис за WAF продолжал быть доступным. Но, правила на WAF не работали — будто их и нет.

Эта история в очередной раз показывает: насколько бывают различны в оценке ситуации разработчики и "безопасники". Более интересный вариант — когда разработчики считают, что только они могут решать: что является уязвимостью, а что — нет (подробнее об этом я писал в статье "Как я зарегистрировал CVE и разозлил вендора").

Теги:
Всего голосов 1: ↑0 и ↓1-1
Комментарии0

Экономия памяти со __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 байтов

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

---
Важные ограничения

  1. Стоит отметить, что реализация __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
    
  2. Важно, не забывать расширять слоты, если мы добавляем в код класса новые атрибуты:

    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
    
  3. В подклассах от класса со __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 ... теперь слоты используются корректно в подклассе
Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Команда проекта Pencil.dev обновила сервис и теперь он генерит любые интерфейсы по клику. В решение внедрили режим «Рой», который создаёт сразу несколько вариаций вашего проекта с помощью шести ИИ‑агентов параллельно. Можно грузить любые файлы и даже кастомные шрифты. Проект поддерживает Antigravity, Copilot, Gemini CLI, Opus 4.6, Sonnet 4.6 и даже OpenCode. Результат можно экспортировать во всех самых популярных форматах: PDF, JPG, PNG и WebP. Также стало доступно полноценное приложение для Windows.

Теги:
Рейтинг0
Комментарии0

Особенность Joomla: json-значения для пользовательских полей и их рендер в subform и вне дочерней формы.

Опять длинное название, но куда уж без этого...

Итак, если вы делаете плагин пользовательского поля - его можно использовать через FieldsHelper. И в процессе ваши данные проходят через различные этапы обработки (недавно была статья на эту тему). И может так оказаться, что ваше поле хранит в rawvalue json (и в базе данных соответственно тоже), а в value вы на его основе рендерите значение. Это стандартный подход Joomla. Так работают, например, поля accessiblemedia. Однако, если вы поместили ваше поле в дочернюю форму (пользовательское поле типа subform и включили "Рендеринг значений = Да", то у вашего замечательного поля может появиться поломанный Json в value вместо нормального значения.

Например:

{"basePath":"...","layout":"..."}

❓ Что там под капотом Joomla происходит?

  1. В обычном потоке Joomla сначала вызывает событие onCustomFieldsBeforePrepareField, а потом onCustomFieldsPrepareField.

  2. Внутри subform же для подполей при render_values=1 вызывается только событие - onCustomFieldsPrepareField.

  3. Если преобразование значения (например, json_decode) сделано в вашем плагине только в beforePrepareField, оно не обработает данные для подполя и...

  4. В шаблоне поля строка заэкранируется (htmlentities), кавычки превратятся в тыкву в " и вы получите кривой json, вместо вашего значения.

👉 Собственно полезный совет по Joomla:

Для полей, которые могут жить внутри subform, делайте нормализацию значения и в onCustomFieldsPrepareField тоже, не только в beforePrepareField.

Теги:
Рейтинг0
Комментарии0

Фронтенд 2026: взлеты и падения

Открываешь проект 2020 года и видишь знакомые имена в package.json: create-react-app, enzyme, moment.js, axios. Пять лет назад это был золотой стандарт. Сегодня же эти технологии вызывают у коллег искреннее недоумение: «Зачем это тут?»

Подготовили для вас быстрый, но очень полезный срез того, как за 5 лет поменялась ментальная модель фронтендера. Внутри инструменты реально умерли, разберемся почему SSR/SSG снова в игре, а TypeScript теперь почти must-have, узнаем почему фронтенд всё чаще = full-stack и что с этим делать.

Главный урок 2015→2025: фронтенд развивается циклически. Каждый цикл — это не «прогресс», а перебалансировка компромиссов. Читайте на Хабр в статье «Фронтенд 2026: что умерло, что выжило и что взлетело неожиданно»

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Как понять, что ваш интернет-магазин вот-вот сломается: триггеры и решения для сайтов на Magento

Привет! Это Дмитрий Абакумов magento-разработчик в Далее, и Максим Бровко, тимлид в Далее.

Мы собрали 5 типичных симптомов, которые сигнализируют, что система уже нестабильна — на примере Magento, популярной CMS в сфере e-com.

В первую очередь скажем, что на Magento работают крупные бренды по всему миру. Она гибкая, масштабируемая, с богатой экосистемой. Однако без регулярных обновлений, контроля и DevOps-поддержки любой проект начинает замедляться, сбоить, а со временем — ломаться. Сигналы появляются заранее: сначала падает скорость, потом checkout, потом весь сайт.

Сигнал 1: падение скорости при большом трафике — во время акций и распродаж

Что проверить

  • Узкие места в БД: тяжелые SELECT, отсутствие индексов.

  • Дублирующиеся или вложенные вызовы блоков в Magento layout.

  • Как ведет себя cron и очередь задач.

  • Используется ли Varnish для FPC и/или Redis для общего кеша.

Как чинить

  1. Настроить загрузку тяжелых блоков после рендера страницы — через AJAX.

  2. Внедрить нагрузочное тестирование — k6, Siege, JMeter.

  3. Перенастроить кеш Magento, включить компиляцию DI.

  4. Заложить горизонтальное масштабирование или CDN.

Сигнал 2: долгая загрузка интернет-магазина при обычной посещаемости (более 3 секунд)

Что проверить

  • Логи Magento и серверов: timeouts, ошибки, блокировки.

  • Скорость отклика API.

  • Время сборки layout и количество подключаемых блоков.

Как чинить

  1. Проанализировать профилировку — Xdebug, New Relic.

  2. Отключить неиспользуемые плагины и модули.

  3. Настроить мониторинг производительности и ошибок — New Relic, Grafana, Prometheus.

Сигнал 3: Клиенты доходят до оформления, но не покупают — особенно на мобильных устройствах

Что проверить

  • Как работает checkout: отрисовка, JS, блоки, сторонние виджеты доставки/оплаты.

  • Как отрабатывает кнопка «Оформить заказ» — все ли проходит быстро.

  • Нет ли тяжелых или повторяющихся вызовов.

Как чинить

  1. Кешировать доступные блоки внутри checkout.

  2. Упростить форму и ускорить ввод данных — DaData.

  3. Включить асинхронную обработку заказов, если оформление занимает много времени.

  4. Протестировать на реальных устройствах и подключить фронтовый логгер — Sentry.

Сигнал 4: когда починили один баг — появился другой 

Что проверить

  • Архитектуру модулей: tight coupling, перезапись классов, обилие around-плагинов.

  • Есть ли автотесты, CI.

  • Как внедряются хотфиксы.

Как чинить

  1. Минимизировать around-плагины и preference (перезаписей классов), отдавать предпочтение before/after-плагинам и observer.

  2. Покрывать фиксы хотя бы базовыми unit/integration-тестами.

  3. Настроить dev → stage → prod, релизный процесс с changelog.

  4. Ввести code style, практику ревью и договоренности внутри команды.

Сигнал 5: CMS или модули устарели, все «на костылях» и никто не решается трогать

Что проверить

  • Версии ядра Magento и зависимостей.

  • Нет ли deprecated-библиотек, особенно JS.

  • Насколько кастомно переопределены шаблоны и классы.

  • Есть ли onboarding-документация, описание архитектуры, миграций, cron.

Как чинить

  1. Если кастомный код внесен прямо в ядро Magento, то его нужно вынести в отдельные модули.

  2. Сравнить архитектуру с best practices Magento и рекомендациями вендоров.

  3. Написать README и настроить автоматизацию — Docker, Ansible.

  4. Запланировать регулярные апдейты проекта.

Если у вас совпадают 3+ пункта — пора на техаудит

Magento почти всегда подает сигналы заранее: снижается скорость, растет количество багов, страдает checkout. Если таких симптомов становится много — пора остановиться и разобраться, что происходит внутри.

Что делать

  • Использовать метрики: PageSpeed, TTFB, логи ошибок.

  • Провести аудит: кеш, модули, layout, архитектура, DevOps.

  • Найти узкие места и критичные зависимости.

  • Выделить приоритеты по улучшениям и составить roadmap по рефакторингу.

Теги:
Всего голосов 2: ↑1 и ↓1+2
Комментарии0

Разбираемся как принимать звонки в браузере. Основы WebRTC\SIP\RTP.

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

Начнем с самой простой в реализации схемы, в которой передача голоса осуществляется напрямую между браузером пользователя, открывшего ваше web приложение и серверами провайдера "виртуальной телефонии"(aka "виртуальная атс" ).
При этом вся мета информация о поступившем входящем звонке и событиях всего жизненного цикла звонка принимает ваш backend. У разных провайдеров телефонии набор событий и строения api может отличаться, но общая схема работы схожа.

Разберем основную схему организации передачи голоса. Браузер по сути работает как SIP‑телефон: сигнализация через WebSocket, медиа — по RTP.

Упрощенно схему работы WebRTC/SIP можно разделить на "регистрацию", "звонок" и "завершение":
Упрощенно схему работы WebRTC/SIP можно разделить на "регистрацию", "звонок" и "завершение":

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 о разработке в стартапах рассказываю еще больше интересного и делюсь опытом, заходите, буду рад!

Спокойных вам релизов и захватывающих решений !

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии0

В чём подвох пожизненной гарантии на сайт


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

Вообще, сайт сам по себе не ломается. Это или баг, который не нашли при разработке, или влияние внешних сил:

  1. Поменялось API у системы, с которой сайт интегрирован. Гугл почта включила режим паранойя, ЯндексКарты формат запроса, чат гопоты стал хотеть другой прокси-сервер.
    И сайт уже работает не так, как задумывалось.

  2. Мамкины хакеры поломали. Если во-время обновлять версии безопасности, сайты вполне могут страдать.

  3. Полозушные руки чужих разработчиков ковырялись в коде. Если нет резервных копий или нельзя откатиться по версиям — это печаль.

  4. Проблема с сервером. Закончилось место на диске, не хватает вычислительной мощности, набежали боты, DDoS-атака

  5. Некорректное отображение в версиях браузеров, вышедших после создания сайта. Это бывает редко, однако возможно, что сайт по прошествии нескольких лет может перестать правильно отображаться в браузерах. Браузеры (Гугл Хром, Опера и другие) постоянно совершенствуются, меняются, перестают поддерживать какие-то устаревшие функции и стандарты.

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

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

ИТОГО. Пожизненная гарантия — полная туфта.

Не играйте в эти игры. Лучше честно сделать договор на техподдержку, где указаны форсмажоры.

Мой тг-канал — Факапы, инсайты, проблемы, взаимоотношения, клиенты, немного юмора.

Теги:
Всего голосов 10: ↑7 и ↓3+5
Комментарии3

Спустя почти год работы мой 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. Фото с пивом сюда выставлять не буду, но представьте, что оно тут есть.

Теги:
Всего голосов 9: ↑9 и ↓0+11
Комментарии14

ИИ в техподдержке SpaceWeb решает каждый четвертый запрос

В SpaceWeb ИИ-ассистент стал полноценным инструментом для работы с запросами веб-разработчиков. Сегодня нейросеть полностью закрывает 23,5% обращений пользователей, а ещё в 64% случаев помогает специалистам поддержки формировать ответы.

ИИ берет на себя типовые задачи, с которыми разработчики сталкиваются при запуске и сопровождении сайтов: подключение доменов и SSL, установка CMS, настройка почты, работа в панели управления. Среднее время ответа — около 30 секунд вместо 10–15 минут у человека. В месяц бот самостоятельно обрабатывает более 1200 запросов.

За счет этого нагрузка на сотрудников поддержки снизилась на 9,5%, а эксперты смогли сосредоточиться на сложных и нестандартных кейсах. Для дообучения модели используется обратная связь от пользователей — ответы ИИ можно оценивать лайками.

Как именно устроена работа ИИ-ассистента, какие сценарии он закрывает уже сейчас и зачем SpaceWeb внедрял нейросеть в поддержку — читайте на сайте.

Теги:
Всего голосов 5: ↑4 и ↓1+5
Комментарии0

Представлен открытый проект PeerWeb — децентрализованного веб‑хостинга на базе WebTorrent. Решение обеспечивает децентрализованный, устойчивый к цензуре веб‑хостинг через пиринговые сети. «Загружайте свои статические веб‑сайты и делитесь ими по всему миру, не полагаясь на централизованные серверы и не оплачивая хостинг», — пояснили авторы решения.

Теги:
Всего голосов 4: ↑4 и ↓0+4
Комментарии0

Ближайшие события

Проект HTTP Cats (GitHub) позволяет использовать котиков в разных ситуациях для объяснения сетевых ошибок и проблем в работе веб-систем.

Теги:
Всего голосов 5: ↑5 и ↓0+6
Комментарии7

Selectel открыл первую часть курса по JavaScript

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

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

  • для чего разработчики используют JavaScript,

  • как работать с со скриптами, веб-страницами и переменными,

  • как создать рабочее окружение на IT-инфраструктуре Selectel.

Участники курса смогут бесплатно протестировать сервисы Selectel, а по итогам тестирования — получить сертификат о прохождении. 

Начните изучение курса прямо сейчас → 

Теги:
Всего голосов 4: ↑4 и ↓0+6
Комментарии0

Событие 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-сообщества

Теги:
Рейтинг0
Комментарии0

Пост о наболевшем. 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 (вот тут и сидим), можно подключить другие каналы
— Могу отправлять сообщения, реагировать

🏠 Умный дом / устройства
— Если подключишь ноды — камеры, уведомления на телефон

🤖 Сложные задачи
— Могу запускать саб-агентов на длинные задачи в фоне

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

И соответсвенно мой список вопросов:
Стоит ли брать платную модель? И какую брать если, уж брать?
Насколько я понимаю штука супер небезопасная, а если запускать из песочницы, то все равно прийдется давать какие-то доступы?
Какие есть альтернативы? Уж очень понравился способ взаимодействия через ТГ

Теги:
Всего голосов 6: ↑0 и ↓6-6
Комментарии2

Представлен открытый веб-редактор изображений DPaint.js (онлайн-версия) на JavaScript, созданный по образцу легендарного Deluxe Paint, с упором на ретро-форматы файлов Amiga. Помимо современных форматов изображений, DPaint.js может читать и записывать файлы иконок Amiga и изображения IFF ILBM.

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

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Коллеги привет, искал себе решение как реагировать на изменения в объекте и нашел отличный сервис, который используется внутри директив таких как 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 по необходимости
    }
  }
}
Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Онлайн сервис проверки конфига nginx на безопасность (Gixy-Next)

На Хабре уже упоминался Gixy как средство проверки безопасности\хардеринга nginx (статья раз, статья два). Недавно появился ещё один проект, основанный на форке Gixy: Gixy-Next (репозиторий, сайт проекта). Из интересного: прямо на сайте есть возможность проверить конфиг nginx (если по какой-то причине не хочется устанавливать приложение). В тексте найденных проблем - ссылки на страницы с подробным описанием типа ошибки.

Результат проверки конфига
Результат проверки конфига
Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0