Bindable в Svelte — это, конечно, “вау, магия”, но давайте не будем забывать, что за эту магию кто-то платит. Попробовал вчера переписать компонент с ручных dispatch на $bindable — вроде красиво, но как только начал кидать в пропсы вложенные объекты, всё посыпалось. Оказалось, Svelte не трекает изменения глубже первого уровня, и пришлось городить костыли с writable или ручным update(). Сравнивать это с Vue/React — ну вы смелые. Там хоть понятно, где и как обновляется состояние, а тут “привязал и забыл” — пока не получишь баг, который воспроизводится только во время лунного затмения. А кто-нибудь тестировал, как $bindable работает с SSR? У меня в SvelteKit компоненты начали падать при гидрации, когда привязки шли через пропсы. Пришлось откатывать на export let value и createEventDispatcher — зато теперь коллеги думают, что я гуру, который “не идёт на поводу у модных фич”. P.S. Автор, спасибо за статью, но давайте честно: это же просто синтаксический сахар для ленивых, а не революция?

Cloudflare и AWS Shield — это как стрелять из пушки по воробьям для маленьких проектов. А если денег нет, то остаётся только iptables и молитвы. Кто-нибудь пробовал CrowdSec ? Говорят, бесплатно и не требует продажи почки. И да, автор, спасибо за примеры, но где мем про “а что, если DDoS всё-таки пробьёт”? P.S. CAPTCHA на API — это жесть. Лучше уж сразу ботов отстреливать.

Бывают такие случаи когда можно запороть ТВ параметр с значениями по умолчанию, по этому возможно следующий скрипт вам поможет: <?php $categoryId = 123; // ID категории $tvName = 'my_custom_tv'; // Код TV $newValue = 'Новое значение'; $criteria = [ 'class_key' => 'modResource', 'parent' => $categoryId ]; $count = 0; foreach ($modx->getIterator('modResource', $criteria) as $resource) { $resource->setTVValue($tvName, $newValue); if ($resource->save()) { $count++; } } echo "Обновлено TV-параметров: {$count}"; ?>

Честно говоря, я даже в подробности не вдавался как все это очко работает. Знаю что V8 - это мотор на крузаке

[image: 1748594124789-7c00b9bb-4ee5-432d-8b69-8421da94bf6a-image.png] PostgreSQL — один из самых мощных и гибких реляционных СУБД с открытым исходным кодом. Однако без должной оптимизации даже самая продуманная система может столкнуться с проблемами производительности. В этом руководстве мы рассмотрим ключевые аспекты оптимизации PostgreSQL, от базовых принципов до продвинутых техник. Мониторинг и анализ производительности Основные инструменты -- Активные запросы SELECT pid, usename, application_name, query, state FROM pg_stat_activity WHERE state = 'active'; -- Долгие запросы (> 5 секунд) SELECT now() - query_start AS duration, query, state FROM pg_stat_activity WHERE state = 'active' AND now() - query_start > '5 seconds'::interval; pg_stat_statements Включение модуля для анализа запросов: ALTER SYSTEM SET shared_preload_libraries = 'pg_stat_statements'; CREATE EXTENSION pg_stat_statements; -- Топ-5 самых ресурсоемких запросов SELECT query, calls, total_time, rows, 100.0 * shared_blks_hit / nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent FROM pg_stat_statements ORDER BY total_time DESC LIMIT 5; EXPLAIN и EXPLAIN ANALYZE Разбор плана выполнения запроса: EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 123 AND order_date > '2023-01-01'; Эффективное использование индексов Типы индексов и их применение Тип индекса Описание Идеальные сценарии B-tree Стандартный индекс Равенство, диапазоны, сортировка GiST Generalized Search Tree Геоданные, полнотекстовый поиск GIN Generalized Inverted Index Составные типы, полнотекстовый поиск BRIN Block Range Index Очень большие таблицы, временные ряды Hash Хэш-индекс Только операции равенства SP-GiST Space-partitioned GiST Неравномерные структуры данных Оптимизация индексов Покрывающие индексы (INCLUDE): CREATE INDEX orders_customer_date_idx ON orders (customer_id) INCLUDE (order_date, total_amount); Частичные индексы: CREATE INDEX active_users_idx ON users (email) WHERE is_active = true; Анализ использования индексов: SELECT schemaname, relname, indexrelname, idx_scan, 100 * idx_scan / (seq_scan + idx_scan) AS idx_usage_percent FROM pg_stat_user_tables WHERE seq_scan + idx_scan > 0; Оптимизация запросов Распространенные антипаттерны N+1 запросов: Проблема: Множество отдельных запросов вместо одного Решение: Использовать JOIN и агрегацию Избыточные данные: -- Неоптимально SELECT * FROM customers; -- Оптимально SELECT id, name, email FROM customers; Неэффективные JOIN: Всегда фильтруйте данные перед соединением таблиц Оптимизация сложных запросов CTE vs подзапросы: -- Часто неоптимально (материализация) WITH recent_orders AS ( SELECT * FROM orders WHERE order_date > now() - interval '30 days' ) SELECT * FROM recent_orders JOIN customers USING (customer_id); -- Оптимальная альтернатива SELECT * FROM orders o JOIN customers c USING (customer_id) WHERE o.order_date > now() - interval '30 days'; Оконные функции вместо кореллированных подзапросов: -- Неоптимально SELECT name, (SELECT COUNT(*) FROM orders WHERE customer_id = c.id) AS order_count FROM customers c; -- Оптимально SELECT name, COUNT(o.id) OVER (PARTITION BY customer_id) AS order_count FROM customers c LEFT JOIN orders o ON o.customer_id = c.id; Конфигурация сервера Ключевые параметры памяти # postgresql.conf # 25-40% от общей памяти shared_buffers = 8GB # Для операций сортировки и соединения work_mem = 32MB # Для операций обслуживания (VACUUM, CREATE INDEX) maintenance_work_mem = 2GB # Размер кэша ОС для данных effective_cache_size = 24GB Правильная настройка параметров памяти критически важна для производительности PostgreSQL. Рассмотрим ключевые параметры с формулами расчета и практическими рекомендациями. shared_buffers (общий буферный кэш) Назначение: Основной кэш для данных и индексов Рекомендации: # Формула для систем с > 4GB RAM: shared_buffers = min(25% RAM, 8GB) для OLTP shared_buffers = min(40% RAM, 32GB) для OLAP # Примеры: RAM 16GB → 4GB (16 * 0.25) RAM 64GB → 8GB (предел для OLTP) RAM 256GB → 32GB (для OLAP) Особенности: Не должен превышать 40% RAM Для Windows: не более 512MB-1GB из-за архитектурных ограничений После изменения требуется перезагрузка сервера work_mem (память для операций) Назначение: Память для сортировки, хешей, оконных функций Рекомендации: # Формула: work_mem = (RAM - shared_buffers) / (max_connections * параллельные операции) # Безопасный расчет: work_mem = (RAM - shared_buffers) / (max_connections * 3) # Пример для 16GB RAM, 100 подключений: (16384MB - 4096MB) / (100 * 3) = 12288 / 300 ≈ 40MB Важно: Значение задается на операцию, а не на соединение Один запрос может использовать несколько раз work_mem Типичный диапазон: 4MB-64MB Слишком высокое значение → риск OOM (out of memory) maintenance_work_mem (память для обслуживания) Назначение: Операции VACUUM, CREATE INDEX, ALTER TABLE Рекомендации: # Формула: maintenance_work_mem = min(10% RAM, 1GB) для баз < 50GB maintenance_work_mem = min(5% RAM, 10GB) для крупных БД # Примеры: RAM 16GB → 1GB RAM 128GB → 10GB (макс. эффективное значение) Особенности: Можно временно увеличивать для операций перестроения индексов Не влияет на обычные запросы effective_cache_size (оценочный параметр) Назначение: Оценка доступного кэша ОС для планировщика Рекомендации: # Формула: effective_cache_size = (RAM - shared_buffers) + файловый кэш ОС # Практическое правило: effective_cache_size = 50-75% от общего RAM # Пример: RAM 64GB → 40GB Важно: Это информационный параметр, не выделяет реальную память! temp_buffers (временные буферы) Назначение: Буферы для временных таблиц Рекомендации: # По умолчанию 8MB обычно достаточно # Для ETL-процессов: temp_buffers = 16-256MB huge_pages (большие страницы памяти) Назначение: Уменьшение накладных расходов Рекомендации: huge_pages = try # или on для включенных систем Требования: Необходима настройка в Linux: vm.nr_hugepages Расчет страниц: nr_hugepages = ceil(shared_buffers / 2MB) wal_buffers (буфер WAL) Назначение: Кэш для записей журнала Рекомендации: # Автовычисление обычно достаточно # Ручная настройка: wal_buffers = max(shared_buffers * 0.03, 16MB) # Пример для shared_buffers=4GB: 4096MB * 0.03 ≈ 123MB → 128MB Формулы расчета для разных размеров БД Для сервера 8GB RAM (небольшая БД) shared_buffers = 2GB work_mem = 8MB maintenance_work_mem = 512MB effective_cache_size = 6GB wal_buffers = 16MB Для сервера 64GB RAM (производственная БД) shared_buffers = 16GB work_mem = 32MB maintenance_work_mem = 8GB effective_cache_size = 40GB wal_buffers = 128MB temp_buffers = 64MB Для сервера 256GB RAM (аналитическая БД) shared_buffers = 32GB work_mem = 128MB maintenance_work_mem = 32GB effective_cache_size = 180GB wal_buffers = 256MB temp_buffers = 256MB Практические советы по настройке Постепенная оптимизация: # Шаг 1: Настройте shared_buffers # Шаг 2: Оптимизируйте work_mem на основе EXPLAIN ANALYZE # Шаг 3: Настройте maintenance_work_mem под размер индексов Мониторинг использования: -- Потребление work_mem SELECT query, work_mem, max_work_mem FROM pg_stat_activity WHERE state = 'active'; -- Эффективность кэша SELECT sum(blks_hit) * 100 / (sum(blks_hit) + sum(blks_read)) AS hit_ratio FROM pg_stat_database; Динамическая корректировка: -- Временное увеличение для тяжелой операции SET LOCAL work_mem = '256MB'; CREATE INDEX CONCURRENTLY ...; Автоматизация расчета: Используйте инструменты: PGTune PoWA для сбора статистики pg_qualstats для анализа предикатов Распространенные ошибки Слишком высокий work_mem: -- При 100 подключениях: work_mem = 256MB → потенциальное использование 25.6GB -- Риск: OOM killer завершит процессы PostgreSQL Недостаточный maintenance_work_mem: VACUUM и CREATE INDEX будут работать медленно Увеличивает время обслуживания БД Игнорирование effective_cache_size: Планировщик будет недооценивать стоимость сканирования по индексу Результат: выбор полного сканирования таблицы вместо индекса Параметры планировщика # Стоимость чтения последовательного блока seq_page_cost = 1.0 # Стоимость чтения случайного блока (для SSD уменьшить) random_page_cost = 1.1 # Параллельное выполнение max_parallel_workers_per_gather = 4 min_parallel_table_scan_size = 8MB Настройки автовакуума autovacuum_vacuum_scale_factor = 0.05 autovacuum_analyze_scale_factor = 0.02 autovacuum_vacuum_cost_limit = 2000 autovacuum_naptime = 1min Расширенные техники оптимизации Табличное партиционирование -- Создание партиционированной таблицы CREATE TABLE orders ( id SERIAL, order_date DATE NOT NULL, customer_id INT NOT NULL, amount NUMERIC(10,2) ) PARTITION BY RANGE (order_date); -- Создание партиций CREATE TABLE orders_2023_q1 PARTITION OF orders FOR VALUES FROM ('2023-01-01') TO ('2023-04-01'); CREATE TABLE orders_2023_q2 PARTITION OF orders FOR VALUES FROM ('2023-04-01') TO ('2023-07-01'); Репликация и шардирование Архитектура высокой доступности: Основной сервер (Primary) | v Синхронная реплика (Sync Standby) | v Асинхронные реплики (Async Standby) -> Читающие реплики Шардирование с помощью Citus: -- Создание распределенной таблицы SELECT create_distributed_table('orders', 'customer_id'); -- Выполнение запроса на всех шардах SELECT * FROM orders WHERE customer_id = 12345; Использование расширений -- Кэширование сложных запросов CREATE EXTENSION pg_pooler; -- Сжатие данных CREATE EXTENSION pg_compression; -- Ускорение JOIN CREATE EXTENSION pg_ivm; Техники обслуживания БД Стратегии вакуума ALTER TABLE orders SET ( autovacuum_vacuum_scale_factor = 0.01, autovacuum_vacuum_cost_delay = 5 ); -- Ручной вакуум для больших таблиц VACUUM (VERBOSE, ANALYZE) large_table; Перестройка индексов -- Одновременная перестройка без блокировки REINDEX INDEX CONCURRENTLY orders_customer_idx; -- Перестройка всех индексов таблицы REINDEX TABLE orders; Мониторинг состояния БД -- Проверка "раздувания" таблиц SELECT schemaname, relname, n_dead_tup, pg_size_pretty(pg_relation_size(relid)) AS size FROM pg_stat_user_tables WHERE n_dead_tup > 1000 ORDER BY n_dead_tup DESC; Заключение Оптимизация PostgreSQL — комплексный процесс, требующий глубокого понимания как самой СУБД, так и особенностей вашего приложения. Ключевые принципы: Измеряйте перед оптимизацией: Используйте мониторинг для выявления реальных проблем Индексы ≠ панацея: Правильные индексы важны, но их избыток вредит производительности Конфигурация контекстна: Нет универсальных настроек — тестируйте под свою нагрузку Проектируйте с учетом масштабирования: Используйте партиционирование и шардирование заранее Автоматизируйте обслуживание: Настройте автовакуум и регулярные проверки Оптимизация PostgreSQL — это постоянный процесс, а не разовое мероприятие. Регулярный мониторинг, анализ производительности и постепенная настройка позволят поддерживать вашу базу данных в оптимальном состоянии даже при росте нагрузки и объема данных.

Я уже довольно давно интересуюсь Linux, и за это время успел попробовать несколько дистрибутивов. Некоторые из них мне понравились, с другими возникли сложности, а про остальные я только читал или слышал от других пользователей. В этой теме я поделюсь своим опытом работы с Ubuntu, Fedora и Kali Linux, а также расскажу о других популярных дистрибутивах, которые пока не пробовал, но планирую. 1. Ubuntu [image: 1740126730830-screenshot-from-2022-04-18-13-05-17-min-min-resized.png] Мой опыт: Ubuntu был первым дистрибутивом, который я установил на свой компьютер. Мне он показался очень удобным для новичков, особенно благодаря простоте установки и большому количеству документации. Я использовал его как основную систему около года, и за это время разобрался с базовыми вещами в Linux. На текущий момент Ubuntu использую под Windows WSL Что понравилось: Простой и понятный интерфейс. Даже если ты раньше никогда не работал с Linux, Ubuntu покажется тебе интуитивным. Большое сообщество. Если что-то не получается, всегда можно найти решение в интернете. Snap-пакеты упрощают установку программ, хотя иногда они работают медленнее, чем традиционные пакеты. Долгосрочные версии (LTS) действительно стабильны. Я использовал LTS-версию, и она отлично работала. Что не понравилось: Иногда обновления могут сломать систему, особенно если ты используешь не-LTS версии. Snap-пакеты иногда занимают много места и работают медленно. Где скачать: https://ubuntu.com/download 2. Fedora [image: 1740126770450-captura_fedora_21_-gnome_shell-min.png] Мой опыт: После Ubuntu я решил попробовать Fedora. Мне было интересно посмотреть, чем она отличается, ведь многие говорят, что это один из самых современных дистрибутивов. Я установил Fedora Workstation с рабочим столом GNOME. Что понравилось: Свежие версии программ. Fedora всегда предлагает последние версии ПО, что мне очень понравилось. Интерфейс GNOME выглядит красиво и современно. Хотя вначале было немного непривычно, но потом я привык. Хорошая производительность. Система работает быстро, даже на не самом мощном железе. Открытость и приверженность свободному ПО. Это вызывает уважение. Что не понравилось: Иногда программы из репозитория могут быть нестабильными, так как они новые. Не все проприетарные драйверы работают “из коробки”. Например, с NVIDIA пришлось повозиться. Где скачать: https://getfedora.org/ 3. Kali Linux [image: 1740126887194-qwe-min.png] Мой опыт: Kali Linux я пробовал исключительно для учебных целей. Я интересуюсь информационной безопасностью, и мне хотелось посмотреть, какие инструменты доступны в этом дистрибутиве. Устанавливал его в VirtualBox, чтобы не трогать основную систему. Что понравилось: Огромное количество предустановленных инструментов для тестирования безопасности. Это действительно удобно, если ты занимаешься этическим хакингом. Частые обновления. Разработчики следят за актуальностью программ. Поддержка различных сред выполнения (Live USB, VirtualBox, VMware). Это позволяет легко экспериментировать. Что не понравилось: Для новичков может быть сложно. Без базовых знаний в области безопасности и Linux здесь делать нечего. Не подходит для повседневного использования. Это специализированный дистрибутив, и использовать его как основную систему нецелесообразно. Где скачать: https://www.kali.org/get-kali/ 4. Debian [image: 1740126905747-74e3ddb8-499e-42ef-8862-eb1493308bb3-image.png] Про Debian я много читал и слышал от других пользователей. Многие говорят, что это один из самых стабильных дистрибутивов, который часто используется на серверах. Также я знаю, что Ubuntu основан на Debian, поэтому они во многом похожи. Особенности: Высокая стабильность. Пакеты тщательно тестируются перед выпуском. Минималистичный подход. Здесь нет лишних “наворотов”, только самое необходимое. Большой выбор пакетов через APT. Можно установить практически любую программу. Подходит для работы как на домашнем компьютере, так и на сервере. Где скачать: https://www.debian.org/distrib/ 5. Linux Mint [image: 1740126945892-0e6425f0-f846-4111-bb3a-702f82e1ee1a-image.png] Linux Mint — это еще один популярный дистрибутив, который часто рекомендуют новичкам. Я читал, что он основан на Ubuntu и предлагает удобный интерфейс, похожий на Windows. Многие пользователи хвалят его за простоту и стабильность. Особенности: Удобный интерфейс Cinnamon, MATE или XFCE. Особенно популярен Cinnamon. Встроенные мультимедийные кодеки и поддержка проприетарного ПО. Не нужно ничего дополнительно устанавливать. Простота установки и настройки. Даже если ты никогда не работал с Linux, разберешься быстро. Хорошо работает даже на старых компьютерах. Где скачать: https://linuxmint.com/download.php 6. Manjaro [image: 1740126979540-mang-min.png] Manjaro — это дистрибутив, основанный на Arch Linux. Я слышал, что он сочетает в себе гибкость Arch и простоту Ubuntu. Многие пользователи хвалят его за удобство и возможность легко настраивать систему. Особенности: Автоматическое обновление ядра и пакетов. Не нужно беспокоиться о совместимости. Есть варианты с разными рабочими столами: XFCE, KDE, GNOME. Большой выбор программ через AUR (Arch User Repository). Простота установки и настройки. Для новичков есть графический установщик. Где скачать: https://manjaro.org/download/ 7. Arch Linux [image: 1740126995895-5f870613-e1db-41cc-bd8b-64bba5d933ed-image.png] Arch Linux — это минималистичный дистрибутив, который предоставляет полный контроль над системой. Я читал, что он больше подходит для опытных пользователей, которые хотят настроить свою систему “под себя”. Пока я не готов к нему, но планирую попробовать позже. Особенности: Rolling-release модель. Обновления выходят постоянно, и тебе не нужно ждать новых версий. Большое сообщество и подробная документация (Arch Wiki). Гибкость и свобода в настройке. Требует ручной установки и конфигурации. Где скачать: https://archlinux.org/download/ Заключение За время работы с Linux я успел попробовать Ubuntu, Fedora и Kali Linux. Каждый из них оставил свои впечатления, и я понял, что выбор дистрибутива зависит от задач, которые ты хочешь решать. Про остальные дистрибутивы я пока только читал или слышал от других пользователей, но планирую их попробовать в будущем. Если ты тоже интересуешься Linux, надеюсь, мой опыт и информация будут полезными. Если у тебя есть вопросы или ты знаешь что-то интересное, пиши в комментариях!

Почитал тут про квантовые алгоритмы и хочу поделиться о том, как квантовая механика превращает классические задачи в “магию” будущего. Да, речь о квантовых алгоритмах Shor и Grover . Не пугайтесь слов вроде “суперпозиция” или “запутанность” — мы разберемся без страшных формул и с юмором . 1. Кубиты: не просто 0 и 1 Классический бит — это как выключатель: либо “вкл”, либо “выкл”. А кубит — это суперпозиция состояний. Представьте монету, которая крутится в воздухе: она одновременно и “орёл”, и “решка”. Квантовый компьютер использует это, чтобы обрабатывать много вариантов сразу. Магия? Нет — физика! 2. Алгоритм Шора: взломай RSA за выходные 🧨 Представьте, что вы хотите разложить число на множители (например, 15 = 3×5). Для маленьких чисел это легко, но для чисел из 1000 цифр? Классические компьютеры тратят миллиарды лет. Shor же делает это за полиномиальное время, используя квантовые свойства. Как? Он превращает задачу в поиск периодичности функции, а потом… бац! — и множители находятся через квантовое преобразование Фурье. Почему это важно? RSA — основа современной криптографии. Если квантовый компьютер с тысячей кубитов станет реальностью, наши пароли станут прозрачными, как стекло 🤯. Но пока что это научная фантастика: даже Google и IBM только начинают осваивать десятки кубитов. 3. Алгоритм Гровера: иголка в стоге сена? Легко! Классический поиск в базе данных из N элементов требует в среднем N/2 шагов. Гровер сокращает это до √N. Как? Он использует интерференцию квантовых состояний, чтобы “подсветить” правильный ответ. Представьте: вы ищете иголку в стоге сена. Классический способ — перебирать каждый соломинку. Гровер же как волшебник, который “чувствует”, где иголка, и направляет вас туда, уменьшая ошибки. Где применяется? Поиск в неструктурированных данных. Взлом симметриичных шифров (но с оговорками). Оптимизация, машинное обучение и даже игры! 4. Жизнь после квантового скачка Квантовые алгоритмы — это не замена классическим, а дополнение. Они круты в задачах, где классические методы терпят крах: Факторизация (Shor). Поиск (Grover). Моделирование молекул (для медицины!). Оптимизация логистики и финансов. Но важно помнить: Квантовые компьютеры пока шумные и ненадежные. Большинство задач по-прежнему решаются классически. Миру нужны программисты, которые умеют думать “квантово”.

[image: 1748517571139-c00fc782-b9a1-4adb-aa63-8a4e8229d340-whichteamareyouin-v0-c9zni0bhmj3f1.webp]