Обновить
467.33

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

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

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

Экономия памяти со __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 ... теперь слоты используются корректно в подклассе
Теги:
+1
Комментарии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
Комментарии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
Комментарии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 о разработке в стартапах рассказываю еще больше интересного и делюсь опытом, заходите, буду рад!

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

Теги:
+11
Комментарии14

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

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

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

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

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

Теги:
+2
Комментарии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

Решил сегодня почитать, что пишут в Ангуляр комьюнити Хабра, и увидел сильно популярный пост с аж 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();
  }
}

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

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

Почему стоит использовать 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}`);
  }
}
Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии1

Представлен открытый проект на 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);

  • готовность к работе: сгенерированные скрипты содержат обработку ошибок, подсказки по вводу текста и документацию;

  • история сеансов: все запуски сохраняются локально с полными журналами сообщений;

  • отслеживание затрат: подробное использование токенов и оценка затрат с поддержкой кэширования.

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