Фронтенд

Хабр, вы надеюсь помните, что у вас есть Темная тема?

nLighten без предупреждения отключил оборудование MIRhosting в Европе

UPD0: возможно причина в этом https://habr.com/ru/articles/1040364/

UPD1: Так же возможно ситуация затронула следующие хостинги:
THE.Hosting
UFO.Hosting
Alexhost.com
Vdsina.com
Hip.hosting
Datacheap.ru
ihc.ru


Оператор дата-центров nLighten в одностороннем порядке и без уведомления остановил работу серверов MIRhosting в Нидерландах и Германии. В MIRhosting назвали действия поставщика абсолютно неприемлемыми.

Что делается сейчас:

• MIRhosting привлекает юристов для выяснения деталей;

• Идутся поиски альтернативных площадок для размещения инфраструктуры;

• Инженеры пытаются восстановить доступ к серверам для спасения данных;

• Готовятся варианты экстренного переезда для клиентов.

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

Материал основан исключительно на данных из открытых источников. Автор публикации не гарантирует достоверность предоставленных сведений и не несёт ответственности за их точность.

Как строить системы, которые выдерживают рост 

Чтобы избежать проблем с производительностью и масштабированием, нужно продумать реализацию на этапе архитектуры. В этой подборке – инженерные решения, которые позволяют системам расти без постоянных переделок. 

Кеширование API: как снизить нагрузку и ускорить систему

Backend-разработчик Doubletapp  рассказывает про кеширование API на примере Jango Ninja: чем оно полезно бизнесу и когда его стоит внедрять. 

Архитектура фронтенда на React без FSD

Собрали архитектурный гайдлайн, который много лет помогает компании разрабатывать проекты клиентов быстро и поддерживать их без боли. Читайте и применяйте на своих проектах! 

Как работают real-time редакторы (CRD, Yjs) 

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

Когда продукт начинает расти, архитектурные решения быстро становятся бизнес-проблемой: система тормозит, новые функции внедряются всё медленнее, а поддержка требует всё больше ресурсов.

В Doubletapp мы помогаем проектировать и развивать сложные веб-системы: от внутренних сервисов до высоконагруженных продуктов с realtime-функциональностью.

Будем рады обсудить ваш проект, если вы:

• масштабируете продукт,

• сталкиваетесь с проблемами производительности,

• запускаете сервис с высокой нагрузкой,

• хотите выстроить архитектуру без постоянных переделок.

Насколько сложный проект можно сделать бесплатно в 2026 году?

Всем привет!
Часто вокруг пишут, как ИИ помогает им «сделать SaaS за выходные», хайпят свои проекты и рассказывают про «миллион фич». Решил я проверить: а что реально можно сделать в 2026 году, если использовать только бесплатные тарифы и не тратить деньги?

Спойлер: получилось достаточно много.

Проект полностью экспериментальный — положится в портфолио.

Я решил сделать большой каталог, и выбрал в качестве товара приложения — PWA приложения — вдохновлялся App Store.

Что в итоге умеет платформа

Для пользователей:

- Личный кабинет с библиотекой своих приложений и избранным

- Можно оставлять комментарии, отзывы, лайки

- Сортировка по категориям, похожим на те, что в App Store

- Поиск приложений умный, использует векторное пространство имен от Google

- Приложения ранжируются по рейтингу — расчет по известной байесовской формуле — учитывает количество установок, отзывов, лайков и качество комментариев

- Задействованы, кажется, все методы установки на топ известных браузеров: от новой (2024) в один клик прямо с нашей платформы — для обладателей Chrome на ПК/Android — до пошаговых интерактивных инструкций в тех браузерах, где установка сложна или запутана

- 20 языков, 2 темы, работает офлайн. Сама платформа — тоже PWA.

Для разработчиков:

- Полноценный кабинет разработчика: управление/настройка приложений

- ИИ-перевод на 20 языков при публикации

- Импорт данных приложения со страниц AppStore и RuStore

- Автогенерация промо-картинки приложения + автопубликация в Pinterest

- Встраиваемый install-скрипт — один тег <script> на сайте разработчика добавляет умную кнопку установки

- 3 разных способа верификации приложений

Контентная часть:

- Масштабируемые промо-лендинги о преимуществах PWA

- Статьи-гайды по установке популярных приложений

- Для админа тоже есть свой интерфейс с множеством настроек

БД (Postgres + pgvector)
Supabase — $0

Серверные функции
Vercel + Edge Functions — $0

Фронтенд
Vercel — $0

ИИ с API (переводы, эмбеддинги)
Gemini — $0

Умный поиск
Google Generative Language API + Gemini

Email
Resend — $0

Авторизация
Supabase Auth (Google, GitHub, Discord, GitLab и др.) — $0

Есть пару оговорок:

- Cursor 20$ в месяц — но я и без проекта его покупал

- и доменное имя wapps.store — 8$ за год. Можно было использовать то, что предоставляет Vercel бесплатно

Меня как фронтенд разработчика впечатлил масштаб бесплатных сервисов — да действительно можно реализовать свою задумку и протестировать её на будущих пользователях.

Однако надо понимать:

- бесплатные тарифы не потянут каких-то весомых нагрузок

- вайбкодить, не понимая, что генерирует нейронка — ну такое себе. Она стабильно ошибается каждый 2–3 раз и часто просто делает дикие вещи

- ну и времени приходится потратить немало, поэтому стоит подумать несколько раз: нужно ли тебе что-то такое просто «потестировать»

Поделитесь своими примеры или существующими проектами - будет интересно!

Мультиязычность в стартапе

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

Если вы сразу сделаете сервис на 10 языках, вы замучаетесь это поддерживать. При любом изменении интерфейса вам нужно будет изменять файлы переводов на всех языках. Хотя большинство ваших пользователей скорее всего поймут интерфейс на английском. Но если вы делаете проект для определенной страны, делайте его на языке этой страны и не добавляйте английский. Даже 2 языка на старте хуже, чем 1 язык. При одном языке вы можете добавлять текст прямо в код и не выносить в отдельные файлы переводов.

Blog • Telegram

Кто такой UX/UI разработчик на практике?

Чем он занимается в реальной приземленной разработке?

P.S. делаю программу для завода и глазам больно от интерфейса

Как прокачаться во frontend-разработке на React?

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

Постепенно появились инструменты, которые упростили эту работу. И один из главных — React. Его используют в самых разных проектах, от небольших сервисов до крупных продуктов. К тому же, во многих командах он стал базовым инструментом.

Кстати, разработчикам, которые умеют работать с React, обычно проще искать работу и получать повышения, а у нас на Хабр Карьере как раз собраны курсы, которые помогают освоить этот востребованный на рынке стек.

Вот технологии и навыки, которые вы освоите на курсах:

— React. Создаем интерактивные пользовательские интерфейсы.

— TypeScript. Расширяем возможности работы с JavaScript.

— Playwright. Автоматизируем тестирование веб-приложений.

— Redux Toolkit. Делаем разработку более лаконичной и удобной.

— Рефакторинг. Улучшаем структуру и архитектуру кода.

→ Повышаем вероятность трудоустройства тут

Туц-туц-туц. Слышите?

Это звуки Техно-Квартирника, нашей регулярной неформальной встречи сообщества A?.Frontend. В этот раз встречаемся в Москве, в нашем ИТ-офисе на Технопарке, и онлайн — из любой точки мира.

27 мая (среда) в 19:00 переходим в режим «техно», чтобы разобрать примеры, как использовать ИИ-агенты в разработке интерфейсов:

Чистая архитектура frontend-приложений и при чём здесь ИИ-агенты?

Илья Агапов, технический лидер разработки, Данила Звягин, ведущий разработчик, Альфа-Банк

Как я поднял ИИ-агента и снова стал высыпаться: OpenClaw, скиллы и корпоративная рутина

Роман Троицкий, старший разработчик интерфейсов (frontend), Сбер

Как ИИ ломают привычную модель веб-безопасности?

Анастасия Егорова, разработчик интерфейсов (frontend), CozyFrontend

После каждого доклада устроим дискуссию по самым трендовым темам, а в завершении вечера проведём:

• Консультации по ИИ-агентам

• Диджей-сет

• Нетворкинг

Регистрируйтесь

Далее на Holy JS: собираем новую методологию вместо FSD и деплоим резюме

Друзья, мы собираемся на Holy JS —  крупнейшей конфе про разработку с разных ракурсов. 

Дима Дин, фронт-тимлид Далее
«FSD — это беда, спасет только FDA!».
Доклад с разбором методологий и экспериментом — созданием альтернативной архитектуры, которая будет отвечать ожиданиям разработчиков. 
15.05 / 19.00-19.45 / зал 2

Ника Варако, HR-менеджер Далее 
«Резюме как продукт: UX, баги и деплой на рынок вакансий».
Воркшоп, на котором Ника покажет примеры и антипримеры резюме, даст советы и лайфхаки по сопроводительным письмам, а главное — расскажет, как дотянуться до рекрутера в настоящих условиях найма. 
14.05 / 19.45-20.45 / зал 1 (keynote)

Приходите на Holy JS, ждем в зале и на нетворке!

На мою воскресную тусовку в Hacker Dojo зашла азиатская женщина по имени Лили и произошло то, о чем я читал в книжке Chip War. В ней есть эпизод, как американские бизнесмены в 1960-е приехали в Юго-Восточную Азию и были потрясены, как просто использовать местных жителей для сборки всего электронного. Учатся мгновенно, делают точно и быстро, и не выпендриваются, как американские рабочие с их дурацкими профсоюзами.

Итак, Лили - программистка вебсайтов, пишет на Java и TypeScript. Никогда в жизни не прикасалась к паяльнику. Пришла на мой митап с запросом “я хочу сделать CPU из микросхем малой степени интеграции”, то бишь рассыпухи из И/ИЛИ/НЕ, D-триггеров, мультиплексоров, 4-х битных сумматоров итд. Как делали в конце 1960-х.

Я ей сказал, что готов помочь ей удовлетворить ее желание, но на это потребуется до хрена таких микросхем. Даже чтобы сделать аккумуляторный процессорик с тремя регистрами (счетчик команд, аккумулятор и индексный регистр). Сначала я показал ей как собирать простые гейты на безпаечной макетной плате, а потом предупредил, что если уставить такими целый стол, то будут все время глючить контакты, поэтому лучше паять.

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

Затем я вручил Лили паяльник вместе с пробной платой и гребенкой, и не успел я отвернуться, как она сделала ряд конусов припоя вообще без дефектов. Отказалась от очков с увеличительными линзами, они де только мешают. Вот и первый раз с паяльником.

Долгое время думала, что использовать паттерны на фронте незачем и это больше тема для собесов

Но недавно все-таки удалось использовать паттерн фабрику для фронта и моему счастью не было предела, когда после 30-минутного рефакторинга разъехавшейся вёрстки через Claude, я попросила: "брат, слушай это ж паттерн фабрика, сделай BaseModal тонким, который просто решает, какой компонент отрисовать"

Технически, классический GoF Factory Method подразумевает наследование, а здесь у меня скорее Simple Factory — функция, выбирающая что создать. Но в обиходе все называют это "фабрикой", и я не буду усложнять.

Классический паттерн фабрика на Java:

// Интерфейс
interface Modal {
    void open();
    void close();
}

// Конкретные реализации
class Dialog implements Modal { ... }
class BottomSheet implements Modal { ... }
class FullscreenSheet implements Modal { ... }

// Фабрика — решает какой класс создать
class ModalFactory {
    static Modal create(String type, boolean isMobile) {
        if (!isMobile) return new Dialog();

        return switch (type) {
            case "bottom-sheet" -> new BottomSheet();
            case "fullscreen"   -> new FullscreenSheet();
            default             -> new Dialog();
        };
    }
}

// Использование
Modal modal = ModalFactory.create("bottom-sheet", isMobile);
modal.open();

Как это работает во Vue?

На фронте есть <component :is="..."/> - динамический компонент, который рендерит то, что ему передадут. Это и есть наш аналог ModalFactory.create(...).

<!-- BaseModal.vue — фабрика -->
<template>
    <component
        :is="modalComponent"
        v-bind="$props"
        @close="emit('close')"
    >
        <slot />
    </component>
</template>

<script setup>

// Фабричный метод — выбирает компонент
const modalComponent = computed(() => {
    // Desktop → всегда Dialog (центрированный)
    if (!isMobile.value) return BaseDialog

    // Mobile → зависит от mobileStyle
    switch (props.mobileStyle) {
        case 'fullscreen':
            return BaseFullscreenSheet
        case 'bottom-sheet':
            return BaseBottomSheet
        default:
            return BaseDialog
    }
})
</script>

Получился BaseModal, который сам почти ничего не делает.

Он не знает, как устроен dialog.
Не знает, как анимируется bottom sheet.
Не знает, как выглядит fullscreen-модалка.

Он просто маршрутизирует:

BaseModal.vue  
  ├─ BaseDialog.vue    
  ├─ BaseBottomSheet.vue    
  └─ BaseFullscreenSheet.vue  

А каждая конкретная реализация живёт отдельно и отвечает только за себя.

Почему это лучше, чем один большой компонент?

Потому что большой универсальный компонент очень быстро превращается в кашу:

<!-- Каша в template -->
<div
    class="modal"
    :class="{
        'modal--open': open,
        'modal--mobile': isMobile,
        'modal--desktop': !isMobile,
        'modal--fullscreen': isMobile && mobileStyle === 'fullscreen',
        'modal--bottom-sheet': isMobile && mobileStyle === 'bottom-sheet',
    }"
>

А потом туда добавляются:

• разные анимации

• разные отступы и размеры

• разное поведение закрытия

• разные transition

• разные layout-правила

И компонент, который должен был быть базовой модалкой, внезапно становится местом, куда страшно заходить.

С фабрикой проще:

• BaseDialog отвечает за centered dialog

• BaseBottomSheet отвечает за bottom sheet

• BaseFullscreenSheet отвечает за fullscreen

• BaseModal только выбирает, что показать

То есть вместо одного монолита появляется тонкий слой выбора и несколько изолированных компонентов.

И кстати, поделитесь: насколько паттерны актуальны сейчас? Или про них всё рассказали 20 лет назад и хватит говорить о них?

Внимательно рассматривал сайт авито и глубоко философски задумался о законах скатывания продукта в хламину.

Что я считаю хорошим сайтом: максимально отзывчивые и предсказуемые, пусть и возвращающие результаты поиска не моментально. Например, все передовые изделия самого гугла - gmail, всякие промежуточные страницы логинов гугла, личный кабинет поисковой гугло-статистики сайта и почти что угодно подобное гугловое. Всё плавно, предсказуемо. Есть ощущение, что делающие гугловые сайты люди очень хорошо знакомы с внутренностями браузера или там есть менеджер-ревьюер-тестировщик, который пинает сайтоделов ногами до тех пор, пока те не узнают. Всё это предсказуемо работает даже в условиях, что от америки мы находимся на противоположном конце глобуса.

Авито:

1. Всё адово тормозит при рендере. Ему надо дать сильно подумать внутри браузера, прежде чем на что-то уже можно будет нажать. "эти компутеры в космос запускать можно, а вы одну кнопку нормально сделать не можете". Тупая фраза, но мысль передаётся.

2. Даже если сайт уже загружался ранее, то каждый раз он всё равно что-то подгружает и о чём-то там думает, прежде чем дать нажать на какую-нибудь элементарную кнопку, типа сортировки объявлений по дате на поисковой выдаче. Я жму на выпадающий список, а он не выпадает. Почему вы каждый раз заново грузите какой-то лютейший вагон .js - файлов, которые отвечают за эту кнопку и не даёте её нажать, пока это всё не прогрузится, ваши зумеры ещё не изобрели кеширование? Ребатя не понимают таких простых сайто-дизайнерских вещей, что кнопка не может не-нажиматься, если ты её уже показал.

3. Вёрстка, сделанная алкашами: никогда не знаешь что ещё подгрузится и вылезет где-нибудь сверху, отодвинув всё зарендеренное снизу. Что за манера подгрузить какой-то баннер, отложенно непредсказуемо поменяв положение всех элементов управления ниже, к которым юзер уже прицелился? За непонимание даже одной этой элементарной штуки на первом классе всех дизайнерских школ бьют по морде табуретом с размаху.

4. Непродуманные элементы управления в принципе дофига где. Много слабо интуитивного, неудачные расположения, пропадающие элементарные фильтры в непредсказуемых местах. В одной категории фильтр "Б\У" есть, а если подняться в родительскую - уже нет. Почему? Например контр-интуитивен и туп сам факт того, что нельзя просто написать в строке поиска used:1 pricerange:100-500 и просто вывалить кучу всего бу из любых категорий от 100 до 500 руб. Какие-то выпадающие менюшки вокруг логотипа "авито" такие, что раскрываются и загораживают сам логотип, если ты попытался прицелиться в него (чтобы перейти на главную) и чуть промахнулся. Жмёшь на какой-то пункт этой менюшки в итоге.

Я вот просто в целом экономически не понимаю как так получается. Что за АвтоВАЗ? Там у вас победило "можно, а зачем"? За что вы платите 450к/сек фронтендерам? Видимо просто за "желательно ничего не сломать, но внедрить новую кнопку от партнёра". Ну ладно, допустим - корпорация, все заняты митингами и KPI, работать некогда, а исследовать внутренности google chrome и всё оптимизировать - тем более никто не даст. А в гугле почему дают? Там просто денег больше? Там это почему работает, хотя их ЦК КПСС в разы жирнее авитовской корпорации.

Но непонятно ещё и другое: это ведь золотая жила для пилильщиков альтернативных площадок по продаже Б\У хлама? Можно ведь просто не напрягаясь сделать простенький аналог сабжа, хоть и с ужасно медленной модерацией и без кучи нужного сервиса, но который будет просто шикарен по юзабилити в сравнении с сабжем.

Извините, просто подумал вслух о помоечном состоянии user interface сабжа. Интересны скорее законы скатывания продукта в хламину и невозможность выделить бюджет на сравнительно небольшой отдел, доводящий лицо проекта до идеала, причём при условии бесконечных толстых потоков денег. Нельзя уволить на мороз какого-нибудь там директора департамента по HR или корпоративного психолога и закинуть освободившиеся 700 тыр в месяц в какого-нибудь гения в области google-chrome движка?

Как настроить доступ к Избранному — без ЛК и авторизации на сайте

Привет, Хабр! Меня зовут Катя Плаксина, я фронтенд-разработчик в Далее. Хочу поделиться решением, которое позволило реализовать возможность сохранения в Избранное без авторизации для пользователей одного крупного портала.

Почему стало необходимо реализовать такое решение? Во-первых, необходимость авторизации — одна из причин высоких отказов на сайте. Таким образом, мы просто облегчаем путь пользователя до цели. Во-вторых, без авторизации мы не собираем персональные данные, а значит, минимизируем риски, связанные с их хранением и передачей.

В чем технический вызов

Если страница работает через SSR, например, на Astro, серверу нужны данные заранее. Но если весь «источник правды» лежит в localStorage, сервер их не видит — браузерное хранилище доступно только на клиенте. 

Без дополнительной логики страница будет рендериться пустой или требовать авторизации и бэкенда. Нужен промежуточный слой, который позволит передать минимальное состояние Избранного на сервер.

Разделяем хранилище на два слоя

Полный стейт Избранного остается в localStorage — там можно хранить существенно больше данных, чем в cookie, и удобно управлять состоянием на клиенте. 

Легкий SSR-снапшот размещаем в cookie, кладем только favorites_preview:

• первые 3–4 ID в каждой категории,

• активные теги,

• размер.

Сервер читает cookie и рендерит превью Избранного.

Что происходит после гидратации

Когда страница загрузилась, клиент сравнивает cookie и localStorage, дотягивает расхождения, корректно показывает или скрывает пустые состояния.

Чтобы избежать ошибок:

• Добавляем mounted-флаг — не используем браузерные API во время SSR.

• Настраиваем синхронизацию между вкладками через системное событие storage.

• Используем кастомное событие favorites:changed для текущей вкладки. Storage в ней не срабатывает.

В итоге состояние Избранного остается консистентным во всех вкладках.

Почему не хранить всё только в cookie

Можно было ограничиться одним механизмом — хранить Избранное полностью в cookie. Но у такого подхода есть явные минусы:

• cookie ограничены по объему,

• перегрузка HTTP-запросов,

• неудобное управление состоянием на клиенте.

Если хранить всё только в cookie, страдают производительность и масштабируемость решения.

Что получаем в итоге

• На клиенте остается полноценное управление состоянием через localStorage.

• Страница рендерится сразу с данными. Сервер читает легкий снэпшот из cookie и формирует превью избранного ещё до загрузки клиента.

Пользователь может вернуться к Избранному даже на следующий день — при заходе с того же устройства и браузера.

Буду рада узнать о вашем опыте реализации подобных задач в комментариях.

4 статьи для безопасного проектирования и разработки программ

Привет, Хабр! Подготовили для вас подборку полезных материалов по безопасной разработке ПО.

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

Что внутри:

• Процессы и основные риски безопасной разработки.

• Требования безопасности

• Принципы безопасного проектирования

• Безопасное использование сторонних компонентов.

Читайте и сохраняйте в закладки →

Препарируем Lit и находим родовые травмы

Задействованы самые современные веб-стандарты, однако:

• Заявляется отсутствие VDOM, однако он есть, со всеми вытекающими.

• Любое исключение капитально ломает весь компонент.

• Неизбежные конфликты имён компонент всё ломают.

• Адовые тормоза и потребление памяти из-за привязки к DOM.

• Тонны бойлерплейта, если нужна кастомизация хотя бы стилей компонент.

Поблагодарить: https://boosty.to/hyoo
Обсудить: https://t.me/giper_dev

текст перенесён в корпоративный блог
https://habr.com/ru/companies/habr_rutube/articles/1028574/

🌲 Открываем регистрацию на Дебаг Кемп

Мы придумали формат, который давно хотели сами: выбираешься из города, два дня в сосновом лесу на Карельском перешейке — маршрут, костёр, мастер-классы по выживанию, нетворкинг без слайдов и питчей. Просто люди, с которыми интересно, и никакого Slack-а.

📅 6–7 июня 2026 (выходные) 👥 Всего 25 мест — маленький формат, это принципиально.

Цена растёт по мере приближения к дате. Оплатить можно частями через сплит → регистрация

Если вы 💎 практик сообщества — скидка 15% применяется при регистрации автоматически. Ещё не практик, но думаете? Сейчас самый разумный момент.

👀 Узнать больше · 📝 Регистрация

Вопросы — в чат, мы там живём.

Как я запускал российское зеркало для SQL-песочниц: гибридное облако и блокировки Composer

Привет, Хабр! Меня зовут Слава, я развиваю SQL-платформы sqltest.online и sqlize.online для бесплатной тренировки запросов на реальных СУБД (PostgreSQL, Oracle, MariaDB 12.3, MS SQL 2025).

Зачем понадобилось зеркало?

От 30% моей аудитории из РФ стали приходить сообщения: «Сайт открывается только через VPN».

Переносить бэкенд целиком - дорого, сервер завязан на тяжелые СУБД в Docker. Поэтому я выбрал гибридную модель: поднять фронтенд в зоне .ru, оставив бэкенд в Германии.

Архитектура: Фронт в РФ, мозг в Германии

Фронтенд: PHP без фреймворков

Нативный PHP, HTML и JS. Меньше зависимостей - проще деплой. Для RU-зеркала я выбрал SpaceWeb*, где есть отличные бюджетные тарифы и классная поддержка.

sqltest-online.ru (SpaceWeb, РФ)
├── PHP (без фреймворков) + HTML/JS
└── Минимум зависимостей

Бэкенд: Docker Compose

Мощный сервер в Германии у Contabo*, где в контейнерах крутятся MySQL, PostgreSQL, ClickHouse и другие базы. Серьезные СУБД требуют ресурсов, так что всё живет на одной полноценной машине.

Как они общаются?

Пользователь отправляет запрос -> браузер делает AJAX-вызов к .ru серверу -> фронт делает HTTP-запрос к бэкенду в Германии (server-to-server) -> бэкенд выполняет SQL и возвращает результат.

Плюсы схемы:

• CORS не нужен: браузер общается только со своим доменом.

• Бэкенд закрыт: принимает запросы только от white-list IP.

• Задержка минимальна: интерфейс грузится из РФ, тяжелые запросы идут по быстрому каналу серверов.

Резервного бэкенда нет - проект бесплатный, на второй сервер пока нет бюджета. Если падает Германия, ложится всё.

Проблемы деплоя: Composer «ушел в отказ»

С git pull всё прошло гладко, но установка зависимостей зависла намертво.

Проблема: Composer не мог достучаться до packagist.org. Просто бесконечный таймаут, вызванный нестабильностью сетевых маршрутов.

Решение: Поддержка SpaceWeb не стала отписываться «проблема на вашей стороне», а сразу дала адрес HTTP-прокси.

Дело одной команды:

export HTTPS_PROXY=http://proxy.host:port
composer install

(Для Windows: set HTTPS_PROXY=...)

Мораль: При деплое на российские площадки проверяйте доступность packagist.org (curl -v https://packagist.org). Если висит - просите прокси у хостера, не тратьте время на Composer.

Итоги

Зеркало sqltest-online.ru работает. Гибридная схема спасает: пользователи получают быстрый интерфейс без VPN, а запросы улетают на проверенный бэкенд.

Я верю, что образование должно быть доступным. Если для практики SQL нужно включать VPN и ждать по 10 секунд - человек не будет учиться. Зеркало .ru - мой способ сказать: «Продолжайте практиковаться».

А как вы деплоите зависимости на RU-площадки? Используете прокси, зеркала или есть решения изящнее?

* P.S. Ссылки на SpaceWeb и Contabo в статье - реферальные. Сервисами пользуюсь сам и смело рекомендую, а бонусы пойдут на оплату серверов проекта.

Обновили Yandex Cloud Video — облачную платформу для управления видеоконтентом

Cloud Video — сервис на базе видеоплатформы Яндекса, созданной командой Yandex Infrastructure. В новой версии появились возможности для защиты и быстрой обработки контента. Теперь можно добавлять логотипы в видео, загружать ролики с других площадок и управлять задержкой и стабильностью видеопотоков.

Защита контента

В Cloud Video появилась возможность добавлять логотипы в загруженное видео. Это позволит защищать контент от переиспользования и применять новые сценарии для брендирования и рекламы.

Стабильный и быстрый просмотр без задержек

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

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

Новые интеграции

Теперь можно переносить видеоконтент с других хостингов через службу поддержки. Для вузов и образовательных компаний появилась возможность внедрять плеер в LMS‑системы. Это поможет быстрее интегрировать видеоконтент в программы онлайн‑обучения.

Пока везут в Zed нативный diff выделенных кусков кода, с подсветкой, преферансом и барышнями, мы будем пить то, что есть 😁

Скрипт намбер ван:

#!/bin/bash

FILE1="/tmp/clp.saved"

# xclip -o -selection primary > "$FILE1"
wl-paste --primary > "$FILE1"
notify-send "Diff" "Первый фрагмент сохранён"

вешаем на одно сочетание клавиш (у меня, например, для удобства, Alt+Shift+1)
(выбираем на вкус для X11 или Wayland)

Скрипт намбер ту:

#!/bin/bash

FILE1="/tmp/clp.saved"
FILE2=$(mktemp /tmp/clp.XXXXXX)

trap 'rm -f "$FILE2"' EXIT

# xclip -o -selection primary > "$FILE2"
wl-paste --primary > "$FILE2"

if [ ! -s "$FILE1" ] || [ ! -s "$FILE2" ]; then
	notify-send "Ошибка" "Нет текста для сравнения"
	exit 1
fi

meld "$FILE1" "$FILE2"

вешаем на другое сочетание клавиш (у меня, например, Alt+Shift+2)

Изолента и реактивный двигатель — вот всё, что нам нужно. Лучше, чем ничего, по крайней мере…
Первый скрипт сохраняет выделенный текст во временный файл /tmp/clp.saved.
Второй скрипт сохраняет выделенный текст в другой временный файл /tmp/clp.XXXXXX, открывает их оба в нашем любимом Meld, мы на всё это дело любуемся, сравниваем, закрываем Meld, после чего скрипт удаляет этот второй временный файл со случайным постфиксом, чтобы не болтался зря. Первый, /tmp/clp.saved пока остаётся, чтобы было удобно с одним и тем же «первовыделенным» сравнивать несколько вариантов, и его всегда можно переопределить первым скриптом.

Итого: Выделили кусок, Alt+Shift+1, выделили другой кусок, Alt+Shift+2 — смотрим, радуемся! 😁