Назад в будущее Хабра. Трекер 3.0 / Хабр | Веб-студия Nat.od.ua
Назад в будущее Хабра. Трекер 3.0 / Хабр
Приветствуем вас, наши дорогие пользователи! Без долгих предварительных ласк: новый трекер, налетайте 🙂
Назад в будущее
Отгадайте загадку:
Маленький, с зелёной точечкой
Появился 11 лет назад
Ну или через 6 лет после создания Хабра
Посчитали? Ага, и эти 8 лет он проработал практически без изменений
Если бы не заголовок публикации, то вы бы точно не сразу догадались, что речь идёт про трекер. Всё так — первая версия трекера появилась на Хабре в далёком 2012 году. И с тех пор он почти не менялся: ну разве что цвет счётчика событий был зелёным, а стал красным, ну и так, ещё всякое по мелочи.
Казалось бы, зачем трогать то, что и так работает? Аргумент, но если всегда ему следовать, то будет довольно сложно эволюционировать и меняться — в итоге легко оказаться на ровной лужайке и порасти мхом. Поэтому в 2021 мы представили на суд общественности новый трекер (назовём его 2.0), который стал доступен вместе с запуском новой версии Хабра. И если к новой версии Хабра многие привыкли довольно быстро (сейчас ей пользуется 99.5–99.7% посетителей), то новый трекер зашёл далеко не всем.
И что не так?
Трекер 2.0 был основан на «соцсеточной модели», когда пользователь отслеживает конкретные дискуссии (например, пары‑тройки пользователей между собой в одной ветке комментариев) в рамках объектов контента (постов в соцсетях или мессенджерах). А вот отслеживать целиком дискуссию под публикациями (что более характерно для форумов и в том числе Хабра) с такой моделью оказалось менее удобно. Ну или как говорят некоторые, совсем неудобно.
Как решили
Видимо, это тот случай, когда нужно было последовать правилу «работает — не трогай», ограничив изменения в трекере адаптацией механики под новую версию Хабра. Так мы и решили поступить с трекером 3.0, который, по большому счёту, является обновленной (и немного дополненной) версией 1.0.
Это ли не УРА?! 🙂
Интерфейс трекера 3.0
Колокольчик никуда не делся: как и прежде, он индикатор наличия новых событий внутри трекера. При наличии таковых трекер выводит число в формате от +1 до 99+, которое является суммой событий во всех разделах трекера.
Нажатие на колокольчик в трекере версии 2.0 открывало меню, в котором события группировались определённым образом (и да, иногда это было не очень удобно — например, если событий накопилось очень много):
Меню трекера 2.0
Сейчас нажатие на колокольчик будет открывать страницу трекера. К внешнему виду раздела перепривыкать не придётся — это всё те же горизонтальные табы, на которых будет выводиться счётчик новых событий (при наличии таковых). Давайте освежим в памяти содержимое табов — тем более что появился один новый.
Публикации
В этом разделе выводятся последние 20 публикаций (если больше, то появится пагинатор), с которыми вы взаимодействовали. Все уведомления можно отметить как прочитанные с помощью чекбоксов и появляющейся в шапке кнопки:
Можно просмотреть все публикации или только свои.
Нажатие на шестерёнку откроет настройки трекера.
Новый трекер позволяет отслеживать не только статьи и новости (в трекере выводятся их заголовки), но и новую сущность, посты, у которых выводятся первые 60 символов содержимого (так как у них нет заголовка).
Сначала в разделе идут все непрочитанные события с сортировкой по последнему комментарию от ранних к поздним, а потом — прочитанные с сортировкой по последнему комментарию от ранних к поздним. Публикации, которые были скрыты в черновики, пропадают из трекера до того момента, пока не будут опубликованы снова.
Новый раздел — Уведомления
Раздел для различных системных уведомлений, среди которых:
Модератор опубликовал вашу статью из Песочницы.
Модератор вернул статью в Песочнице на доработку.
Модератор отклонил публикацию.
Пользователю становится доступна ППА.
Администратор компании одобрил (или отклонил) заявку на вступление в ряды сотрудников компании.
Если публикация была отправлена модераторам сезона (о прохождении модерации сообщается в личных сообщениях).
В будущем планируем добавить сюда ещё больше уведомлений, полный перечень которых опубликуем в справочном разделе.
В разделе уведомлений та же сортировка (от новых к старым), те же 20 элементов на страницу.
Упоминания
Этот раздел существовал ранее и по сути не изменился — в нём собираются уведомления в том случае, если вас кто-то упомянул в статье или в комментарии. По клику вы попадаете или в статью, или сразу на конкретный комментарий.
Подписки
Сюда попадают уведомления, связанные с вашими подписками или подписчиками. Например, здесь окажется событие, если автор, на которого вы подписаны, выпустил новую публикацию или добавил что-то в избранное. В этом разделе также добавились посты.
Приложения
Хоть у нас пока и было только одно приложение (Анонимный Дед Мороз), мы всё же оставили этот раздел. На вырост.
Мы настроили обратную совместимость между версиями: уведомления из трекера в старой версии должны перенестись в новую.
Надеемся, это изменение добавит вам удобства при использовании Хабра и наконец‑то поможет решить вопрос со старой версией сайта — по нашим опросам, трекер был последним, что заставляло пользователей переключаться на неё.
Пользуйтесь на здоровье! Будем рады любой обратной связи — пишите в комментариях или в личку.
Нашли опечатку в тексте? Выделите и нажмите CTRL/⌘+Enter.
как я выбросил 10-месячный проект после 2 месяцев в должности / Хабр | Веб-студия Nat.od.ua
как я выбросил 10-месячный проект после 2 месяцев в должности / Хабр
Когда я принял управление командой, её участники находились на 8-м месяце реализации 3-месячного проекта по перезапуску коммерческого сайта компании. Спустя два месяца ведения этой команды, я решил отказаться от всего достигнутого и начать сначала. Это история о том, почему я это сделал, как, и что в итоге получилось.
Перезапуск нашего сайта преследовал одну цель: обеспечить быструю отрисовку на стороне сервера.
В удачное время размер нашего JS-бандла составлял 168 МБ. На топовом MacBook Pro среде разработки для начала быстрого реагирования требовалось 3 минуты. Приходя на работу, инженеры уже по привычке вводили npm run dev и шли пить кофе, пока кулеры их компьютеров изо всех сил пыхтели, обслуживая нагрузку, возложенную на них нашим раздутым проектом.
Где же всё пошло не так?
▍ Предыстория
Первым сайтом компании было одностраничное приложение на AngularJS. AngularJS не поддерживал отрисовку на стороне сервера (SSR, server-side rendering), поэтому первая загрузка страницы происходила медленно, и только потом уже всё начинало работать быстро.
А поскольку в интернете играют роль даже миллисекунды, особенно в случае сайтов электронной коммерции, нам нужно было уменьшить время первой отрисовки.
Команда подумывала об использовании Angular 2, и хотя этот фреймворк значительно отличался от AngularJS, он казался логической основой для нового сайта. Мы даже следили за экспериментальной веткой разработки этим проектом функциональности SSR. Естественно, к моменту готовности сайта она тоже должна была быть готова.
Команда создавала сайт, регулярно внося последние изменения из этой экспериментальной ветки в код и разбираясь с возникающими нестыковками.
Я присоединился к ней за две недели до завершения этой функциональности. На тот момент дедлайн нас уже нагонял, но большинство страниц были готовы, и все критические функции работали. Моей задачей было вывести проект в продакшен.
Команда Angular приблизилась к завершению функциональности SSR, и мы привносили последние штрихи в критические маршруты пользователей. Всё шло если не отлично, то по крайней мере… шло. Пока не встало.
У нас был рабочий сайт. Единственное, чего не хватало – это полноценной поддержки SSR. Отрисовка на сервере работала, но не при встряхивании дерева, а AOT-компилятор (критический этап в сборочном конвейере Angular) выдавал бандлы невероятного размера.
Три недели ушло на то, чтобы поставить «приятные бонусы» из списка отложенных задач, включая реально впечатляющее кэширование образов с помощью Nginx (это отдельная история). Мы каждый день проверяли репозиторий Angular в надежде, что там появится критическое исправление.
В итоге приятных бонусов для добавления не осталось, и мы две недели потратили на копание в SSR-ветке команды Angular, но раскидистая, незнакомая база кода и непоправимые ошибки всё сильно затрудняли. Поскольку проект был экспериментальным, толковой документации к нему не было.
Мы тратили время и ни к чему не приходили, хотя чувствовалось, что сдаваться сейчас, когда финиш так близок, будет глупо.
Спустя неделю без какого-либо значительного прогресса и ощутимых действий в апстриме, мои силы были на исходе. На меня всё больше давило руководство, а наши конкуренты определённо не дремали, так что бизнесу нужен был готовый проект.
У нас не было чёткого понимания, как мы сможем поставить имевшийся у нас на тот момент продукт, и встал вопрос: «Можем ли мы позволить себе начать его с нуля?»
Мы оказались в ловушке невозвратных затрат, вкладывая всё больше денег, времени и ресурсов в провальный проект из страха потерять уже вложенные средства.
Если ситуацию не исправить, она неизбежно приведёт ко всё большей потере.
Я не спал ночами, обдумывая решения, которые привели к этому раскладу. По собственному опыту я знал, что React & Redux имели полноценную поддержку SSR.
Я лично видел, как быстро мотивированная команда продвигалась, используя этот стек, но выбрасывание коту под хвост целого года работы очень сильно покачнуло бы дух команды и явно не понравилось бы руководству, которое ожидало от вложенных усилий результатов.
Кроме того, эта мысль противоречила всем инстинктам, которые у меня были относительно масштабных переделок.
▍ Начинаем заново
Самая большая сложность этой затеи заключалась не в технических аспектах, а в личностных. Первым делом нужно было получить одобрение от учредителей. Мне удалось добиться этого, пообещав две вещи:
- Что я буду продолжать следить за проектом Angular SSR, и в случае его выпуска мы тут же запустим сайт на Angular.
- Сайт на React будет доведён до работоспособного состояния за 6 недель, а через 10 мы его уже сможем запустить. Если мне это не удастся, то я пойду на понижение и найду себе замену.
Первое обещание было здравомысленным, а второе отражало мою уверенность, исходящую из личного опыта. Я уже создавал на React сайт с отрисовкой на сервере, и знал, что всё сработает. Если же смотреть с позиции учредителей, то у них имелся чёткий стоп-лосс на случай, если что-то пойдёт не так.
Но самым сложным всё же было получить одобрение от команды. Они провели много месяцев, трудясь над проектом ещё до моего прихода, и теперь я предлагал выбросить всю их кропотливую работу, притом ещё и устанавливая безумный дедлайн на новую. Им нужно было поверить в реалистичность этой затеи и, самое главное, в правильность этого выбора.
Мне требовалось убедить команду использовать стек React, и единственным способом для этого была платформа DevEx. Они должны были увидеть, насколько продуктивно можно работать, если не опираться на их текущие отсталые инструменты.
Я набросал схему проекта React с SSR и выбрал для реализации один поток, установив амбициозную цель создать нашу домашнюю страницу – полностью отзывчивую и с поддержкой SSR – в течение дня моб программирования.
В итоге все были поражены возможностями горячей замены модулей и повторного рендеринга в реальном времени. После проекта, в котором им приходилось ждать отображения изменений вплоть до минуты (в удачный день), это выглядело как магия. Среди команды ещё витал некий скептицизм относительно того, сохранится ли такое быстродействие после создания остальной части сайта, но этой демонстрации было достаточно, чтобы участники команды решили вложиться в реализацию идеи.
Все ценят быстрый цикл обратной связи. Даже короткое ожидание результата изменений может загубить весь рабочий поток.
Вложение усилий в ускорение вашего тестового набора или поиск более производительной системы сборки сокращает этот цикл, а также напрямую повышает вовлечённость и продуктивность команды.
Во второй день мы поделили сайт на 20-30 ключевых пользовательских историй – многие были взяты из первого проекта – приоритизировали их и начали поставлять.
Процесс создания нового сайта происходил онлайн, будучи открытым для всей компании, и к концу первой недели остатки скептицизма испарились, когда все увидели, как далеко продвинулась команда за столь короткий срок.
▍ Поставка
Новый сайт мы поставили, спустя 7 недель сосредоточенных усилий, как раз к одному из самых активных покупательских периодов года. Он был невероятно быстр, в нём использовалось меньше ресурсов, чем в оригинальном сайте на AngularJS, и написанный нами код, спустя несколько лет, до сих находится в продакшене, хотя с тех пор сайт сильно изменился.
Angular Universal с первоклассной поддержкой SSR в итоге был добавлен в Angular v5, вышедший в апреле 2018 года, где-то через шесть месяцев после завершения нашего сайта.
В этом проекте было нарушено два фундаментальных правила управления программными проектами:
1. Не создавайте рабочие приложения с помощью экспериментальных технологий
Версия сайта на Angular как раз создавалась на экспериментальной, неподтверждённой технологии и до сих пор находится в активной разработке.
Это был очень значительный внешний риск, который оставался полностью вне нашего контроля, поскольку мы никак не могли знать, когда никак не отвечавшая перед нами команда Angular поставит свой продукт.
Если бы мы решили продолжать ждать, то простаивали бы вхолостую, не обеспечивая никакой бизнес-ценности в течение 9 месяцев, удвоив продолжительность реализации проекта.
2. Не идите на масштабное переписывание проектов
Решение переписать сайт на Angular 2 без требования следовать поэтапным релизам завело команду в ловушку, вынудив создавать весь сайт до столкновения с основным риском.
Если бы в условиях реализации проекта было заложено требование выпускать поэтапные релизы, то понимание о том, как нужно создавать сайт, возникло бы гораздо раньше.
Здесь внимательный читатель может сказать: «Подождите-ка. Разве проект на React не стал масштабным переписыванием?»
Отвечу так: «Изучайте правила, чтобы знать, когда их можно нарушать».
Я пошёл на сознательное нарушение этого правила, чтобы сохранить мораль команды.
В этом случае я сделал ставку на то, что передовой проект на React сможет сохранить в её участниках мотивацию. Втискивание React в легаси-проект на AngularJS не привело бы к достижению цели, а возвращение к старому коду после нескольких месяцев создания нового нанесло бы сильный удар по духу команды.
Это было очень ситуативное решение. Если бы мы не переходили с провального проекта на Angular 2, то я бы с самого первого дня пошёл на использование одной из прослоек совместимости между React и AngularJS, чтобы перенести сайт постепенно.
Как менеджеру вам нужно играть с той рукой, которая вам выпала, а не с той, какую бы вы хотели получить. Каждая ситуация уникальна, и каждое принимаемое вами решение должно учитывать не только продукт, но и людей, его создающих.
Порой это означает, что вам нужно нарушить устоявшиеся правила. Но помните – у всяких правил есть свои причины, так что не стоит возводить это в привычку.
Telegram-канал с розыгрышами призов, новостями IT и постами о ретроиграх 🕹️
новая архитектура для ресурса с большой нагрузкой / Хабр | Веб-студия Nat.od.ua
новая архитектура для ресурса с большой нагрузкой / Хабр
К нам обратился заказчик, который хотел улучшить архитектуру высоконагруженного ресурса на основе Moodle. Сайт имел привычку падать при высокой нагрузке. Ничего необычного, подумали мы. Берем.
Нетривиальность задачи оказалось в том, что кейсов инсталляции сервисов Moodle на ресурсы с нагрузкой >10 тыс. человек нет ни у Яши, ни у других сервисов, к которым мы привыкли. Из коробки ничего не работало, документации тоже не нашлось. Предыдущий исполнитель с задачей не справился и оставил сервис в печальном состоянии.
Срок выполнения задачи – 2 месяца, что добавило остроты проекту перед Новым годом…
Исходные данные
Легкое ощущение запутанности
Ресурс (сайт) для проведения онлайн-тестирования с использованием системы Moodle со следующими характеристиками:
нагрузка на ресурс периодическая: в пиковые нагрузки – до 12 тыс. онлайн пользователей, в период простоя ~200 человек.
проблема: в пиковые моменты сайт замедлял работу и падал. При этом недостатка в вычислительных ресурсах не было, а вот вопросов к архитектуре – множество.
архитектура: 20 постоянно работающих серверов с разными базами данных в разных дата-центрах, где каждый сервер находился в регионе присутствия компании. Это огромная, неповоротливая архитектура, где для любого обновления нужно делать привязку к каждому отдельному серверу.
подготовка сводной аналитики: данные раз в несколько дней выгружали из каждой базы данных и скриптами сводили вместе все отчеты.
базы данных представляли собой модульную объектно-ориентированную динамическую среду обучения – Moodle.
Налицо неэффективная система обработки данных.
Заказчик столкнулся с проблемой перегрузки серверов и решил ее, просто увеличив количество серверов в 5 раз (хехе). Решение ожидаемо привело к расходам и сложностям со сведением данных с разных серверов в одну базу.
Далее кривая вывела заказчика к другой компании, которая создала множество инстансов баз данных и каждого отдельного Moodle, но проблему так и не смогли решить.
Тут, собственно, задача и попала к нам.
Задачи разработки
Основной запрос – оптимизация архитектуры ресурса. Мы предложили спроектировать архитектуру с динамически изменяемым количеством серверов в зависимости от нагрузки.
Ресурс должен быть представлен в виде единой базы данных, без деления по регионами, иметь единую систему отчетов и выдерживать пиковую нагрузку до 12 тыс. пользователей.
Итак: знаем что делать, но не знаем как. (пока)
Обратный отсчет
Мастера планирования в деле
Для решения задачи наштормили несколько вариантов. Времени делать сложносочиненные решения не было…
Вариант 1: использовать Yandex Cloud (YDB) для создания отдельного программного модуля – коннектора, поддерживающего нативный интерфейс MySQL.
Для Moodle-системы это выглядело как подключение к базе данных MySQL, а коннектор транслировал запрос в YDB.
Сложности подхода: часть функций не поддерживалась, т.е. невозможно было реализовать полную совместимость с MySQL очевидными и быстрыми методами, из коробки. Нагрузочное тестирование показало слабые результаты. Показатели были существенно ниже обычных для MySQL.
От идеи быстро отказались и погнали дальше.
До сдачи 52 дня.
Вариант 2: использование оркестратора базы данных Vitess. Vitess был создан в 2010 году для решения проблемы масштабируемости MySQL, с которыми тогда столкнулась команда YouTube. Пиковая нагрузка превышала пропускную способность базы данных, а использование прокси-сервера между приложением и базой данных для маршрутизации и управления взаимодействием с базой данных позволило решить эту проблему.
Вдохновившись этой историей, мы попробовали взять в работу Vitess.
Ограничивающим фактором стало отсутствие адекватной документации. В результате тестирования получили схожие с первым вариантом результаты. Решение просто не стало работать в режиме кластера!
Мы обратились бизнес-поддержку YDB и выяснили, что и они тоже не работали с такими кейсами. Что ж, отрицательный результат – тоже результат.
До сдачи 41 день.
Настало время последнего варианта. Скажем прямо – на первый взгляд он выглядел так себе… Но, параллельно с работая над предыдущими вариантами, мы проводили ресерч и тесты и постепенно пришли к мысли, что при качественной проработке это может стать хорошим решением.
Лучшее – враг хорошего
Когда ты уже свой в бардаке
Вариант 3: остаться на используемой базе MySQL в режиме кластера из одной ноды (экземпляра). Тут следует заметить, что предыдущий исполнитель, к которому обращался заказчик, решить такую задачу не смог. Он ушел с используемой заказчиком базы и создал множество инстансов баз данных и сервисов Moodle. Его подход, конечно, не нашел продолжения в новой архитектуре. Но идея с базой данной прижилась!
Нам удалось применить однонодовую конфигурацию кластера базы данных MySQL. Мы проверили ее оптимизацию и доработали конфигурации для работы с максимальной нагрузкой на ресурс.
Такой результат был получен за счет “тонкой” конфигурации кластера MySQL в соответствии с поставленной задачей, что позволило достигнуть требуемой пиковой нагрузки на одном экземпляре базы данных
Вова Завьялов, архитектор проекта
Использовали Yandex Managed Service for MySQL® на базе инфраструктуры Yandex.Cloud в качестве платформы для управления кластером базы данных. Конфигурация сервера была следующая:
CPU 96 ядер;
RAM 192 ГБ;
SSD 512 ГБ.
Создание централизованного хранилища
Когда на карту поставлены все котики
До сдачи 30 дней…
Исходная архитектура заказчика была примерно эры динозавров, поэтому мы провели миграцию всех структур и данных на современную контейнерную архитектуру. Но и тут появились проблемы, с которыми мы просели еще на неделю как минимум..
Проблема 1
После миграции перед нами встал серьезный вопрос о хранении данных, т.е. документов, изображений, внутренних файлов. Головоломка была в том, что с увеличением количества серверов мы не должны потерять скорость передачи этих данных.
Оптимизация и адаптация подразумевала необходимость централизовать хранилище, сведя все кластеры серверов в единую систему.
Проблема 2
Проблемой заказчика была трудоемкость работы с базами. Каждый сервер имел свой отдельный moodle, базу данных и файловые системы.
Чтобы свести все данные с каждого сервера использовались заклинания скрипты. Как понимаете, это приводило к хаосу. Идентификаторы связанных серверов пересекались и происходила перезапись данных.
Из хаоса в систему
Чтобы исключить подобные ситуации мы создали сетевое централизованное хранилище.
Хранилище имеет максимальную скорость чтения и записи до 8 Гбит/сек.Доступ к дисковому хранилищу организован через протоколы NFS (network file storage). Настроили RAID-массив и выделили хранилище в отдельный сервер, работающий на CentOS. После проведения тестирования мы перевели платформу на новый уровень порядка и организации и получили достаточно высокопроизводительное хранилище, которое гибко интегрировалось со всеми серверами.
Ищем равновесие
Системе был необходим дирижер динамической архитектуры. В его роли выступил балансировщик нагрузки (!!!), который при росте количества пользователей автоматически создает новые сервера, а при снижении – удаляет сервер через несколько минут после того, как нагрузка спала.
Мы использовали в проекте L7-балансировщик, что позволило в нагрузочном тесте сгладить итоговые результаты за счет поддержки функции Session Affinity, когда балансировщик запоминает пользователя и закрепляет его за определенным сервером бэкенда, что в свою очередь снижает нагрузку на файловый кэш.
По срокам мы вроде еще успевали, но нельзя недооценивать последние этапы.
Итоги
Еще около 12 дней ушло на развертывание сервисов, нагрузочное тестирование и ввод в эксплуатацию. Еще одна непредвиденная проблема и мы бы жестко пролетели со сроками. К счастью, ее не случилось.
По итогу мы собрали пазл из разрозненных серверов в централизованный ресурс.
Для этого:
провели централизацию базы данных;
выполнили оптимизацию конфигурации кластера базы данных MySQL для работы с пиковой нагрузкой до 12 тысяч пользователей;
вывели кэш сессий в Redis;
использовали L7-балансировщик для распределения нагрузки между серверами;
для хранения пользовательских временных файлов создали отдельный NFS-сервер, который может работать на скорости до 8 Гбит/сек.
Заказчик получил централизованную систему, единый Moodle, который может работать при максимальной нагрузке (см пикчу)
Структура управляющей программы
Решена проблема сведения результатов онлайн тестирования из разных баз: теперь данные отображаются в единой базе и администратору доступны сразу все отчеты.
По цифрам
Резко упала стоимость ресурсов в момент простоя платформы. Это главное.
Учитывая сезонность работы сайта, когда большую часть года ресурс работает с минимальной нагрузкой, и только несколько месяцев в году происходит резкий рост пользователей, методы балансировки нагрузки позволяют мощно сократить финансы.
Когда нагрузка отсутствует, ненужные сервера не запущены и заказчик за них не платит.
Сэкономленные деньги – это заработанные деньги
Расчет стоимости ресурсов идет в зависимости от нагрузки на сайт за 1 секунду.
Итого сервис располагает серверами:
баз данных;
файлового хранилища;
сервисные сервера;
сервера бэкенда;
сервера-балансировщики нагрузки, которые создаются под обработку запросов.
Серверов-балансировщиков в пиковые нагрузки может быть до 24 шт. В момент простоя работают только сервер базы данных, сервер хранилища, сервер кэша и один сервер для обработки пользовательских запросов.
Проведя изменения на материнской виртуальной машине необходимых нам данных по веб-интерфейсу, по формам, спискам мы устранили все танцы с бубнами и сделали ее единой точкой входа для всего кластера.
Нагрузочное тестирование показало предельное RPS 200 (Requests Per Second – количество запросов за одну секунду). Цифра превзошла наши ожидания: для нашего проекта это эквивалентно работе 16 тысяч пользователей.
Валера Ковальский, разработчик
Когда разработал в срок в канун НГ
В итоге, Заказчик получил сайт 30 декабря. А мы ушли восстанавливаться 🙂
ADI в пользовательском интерфейсе | Веб-студия Nat.od.ua
ADI в пользовательском интерфейсе
ADI (Artificial Design Intelligence) – это технология, использующая искусственный интеллект (ИИ) для автоматизации дизайна и графики. Её можно применять не только в дизайне, но и в веб-дизайне, архитектуре, производстве и других областях. Основная идея заключается в ускорении и упрощении создания дизайн-проектов, делая их более эффективными и доступными.
Стоит отметить, что ADI – относительно новая технология с постоянно расширяющимися возможностями. Она позволяет исследовать и использовать ИИ для улучшения дизайна и сделать его более инновационным и эффективным. Искусственный интеллект также влияет на дизайн пользовательских интерфейсов (UI).
В настоящее время существует ряд различных инструментов на базе ИИ, которые могут помочь дизайнерам создавать более качественные пользовательские интерфейсы и включают в себя такие аспекта ADI как:
Читать далее
Почему тип поля enum на уровне базы — зло / Хабр | Веб-студия Nat.od.ua
Почему тип поля enum на уровне базы — зло / Хабр
Часто разработчики интересуются почему не рекомендуется использовать тип поля enum в базе данных, и в этой статье мы рассмотрим все плюсы и минусы данного типа.
Тип колонки enum используется для хранения данных, которые могут принимать определённые значения из заранее определённого набора. Он обеспечивает ограничение значений, которые может принимать колонка, и позволяет более строго контролировать данные. Это может быть полезно для хранения статусов, категорий, типов или любых других значений, которые могут быть заданы только из ограниченного набора вариантов.
Но это в теории. А что на практике? Давайте рассмотрим.
Допустим у нас есть таблица со списком игр, содержащая колонку “жанр” (“genre”) со следующими значениями:
CREATE TABLE `games`(
`id` INT UNSIGNED NOT NULL AUTO_INCREMENT,
`title` VARCHAR(255) NOT NULL,
`genre` ENUM(‘action’,’adventure’,’shooter’,’rasing’) NOT NULL,
KEY(`id`)
) CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
Через какое-то время была замечена грамматическая ошибка в слове “racing” и принято решение её исправить.
Нюанс изменения enum поля в том, что при его редактировании сбрасываются значения колонки в null для всех строк таблицы, а то и вовсе получим ошибку `Data truncated for column ‘genre’ at row 3`. То есть, чтобы корректно изменить enum поле, нужно куда-то сохранить данные. План действий будет таков:
Создать новую enum колонку с правильным набором данных;
Скопировать значение из старой колонки в новую и сразу применить исправление значения;
Удалить старую enum колонку;
Переименовать новую enum колонку.
При использовании фреймворка Laravel это будет выглядеть следующим образом:
use IlluminateDatabaseMigrationsMigration;
use IlluminateDatabaseSchemaBlueprint;
use IlluminateSupportFacadesDB;
use IlluminateSupportFacadesSchema;
return new class extends Migration
{
public function up(): void
{
// Создаём новую колонку
Schema::table(‘games’, function (Blueprint $table) {
$table->enum(‘tmp_genre’, );
});
// Копируем значения из enum колонки в новую с корректировкой значения
DB::statement(‘UPDATE games SET tmp_genre = (IF genre = ‘rasing’ THEN ‘racing’ ELSE genre END IF)’);
// Удаляем старую колонку
Schema::table(‘games’, function (Blueprint $table) {
$table->dropColumn(‘genre’);
});
// Переименовываем колонку
Schema::table(‘games’, function (Blueprint $table) {
$table->renameColumn(‘tmp_genre’, ‘genre’);
});
}
};
На языке SQL эти действия будут выглядеть следующим образом:
ALTER TABLE `games`
ADD COLUMN `tmp_genre` ENUM(‘action’,’adventure’,’shooter’,’racing’) NOT NULL AFTER `genre`;
UPDATE `games` SET `tmp_genre` = (
IF `genre` = ‘rasing’
THEN ‘racing’
ELSE `genre` END IF
);
ALTER TABLE `games`
DROP COLUMN `genre`;
ALTER TABLE `games`
CHANGE `tmp_genre` `genre` ENUM(‘action’,’adventure’,’shooter’,’racing’) CHARSET utf8mb4 COLLATE utf8mb4_unicode_ci NULL;
И, кроме этого, всё-равно нужно будет на стороне приложения обрабатывать значение либо как константу класса, либо как enum класс. Например:
class Game extends Model
{
protected $casts = ;
}
enum GameGenreEnum: string
{
case Action = ‘action’;
case Adventure=”adventure”;
case Shooter=”shooter”;
case Racing = ‘racing’;
}
А теперь представьте, что как только эта задача выполнена, пришла новая – добавить новую категорию – `Fighting`…
Альтернатива этой боли – полный отказ от полей типа enum в пользу integer. В этом случае как при изменении названия, так и при добавлении нового всё что нужно будет сделать – это изменить содержимое самого enum класса. Например:
// До
enum GameGenreEnum: int
{
case Action = 1;
case Adventure = 2;
case Shooter = 3;
case Rasing = 4;
}
// После
enum GameGenreEnum: int
{
case Action = 1;
case Adventure = 2;
case Shooter = 3;
case Racing = 4;
case Fighting = 5;
}
И всё. Никакой боли и задача закрывается буквально за несколько секунд.
Именно поэтому многие разработчики отказываются от использования колонок типа enum в базе данных сохраняя не только время, потраченное на задачу, но и нервы и, в качестве приятного бонуса, шанс потерять данные сводится к нулю.
Также можно ответить на вопрос “почему integer, а не string”: дело в том, что поля типа string подвержены грамматическим ошибкам и всё что они дают – лишь удобство чтения таких данных в одной конкретной таблице без использования SQL запросов. Но если в слове будет допущена ошибка или слово нужно будет заменить на другое – придётся отправлять запрос в базу, чего не нужно делать при использовании целочисленных значений.
Таким образом, тип полей enum в базе – это лютое зло.
Добавление server side Open Graph и прочего SEO в существующую SPA / Хабр | Веб-студия Nat.od.ua
Добавление server side Open Graph и прочего SEO в существующую SPA / Хабр
Представьте себе следующую ситуацию: у вас на руках есть SPA с рендерингом полностью на клиенте, и вам необходимо сделать так, чтобы в зависимости от URL было разное содержимое у тега
.Например, ваш шеф просит вас сделать так, чтобы при вставке в Телеграм ссылки на французскую версию сайта с query параметром ?hl=fr появлялась превью с французским заголовком и описанием сайта.
Как раз в такой позиции я оказался некоторое время назад, и мне на растерзание попался сайт на чистом, старом-добром, клиентском Vue.
У любого разработчика, знающего отличия SSR и CSR, первым инстинктом будет сказать, что это просто невозможно, а если и возможно, то надо переписывать сайт на Nuxt или хотя-бы на Vite SSR, на что уйдет парочка спринтов.
Но если вы не боитесь замарать руки о костыли, то есть и другой способ! Идея очень проста – пишем сервер на Node, который будет отдавать наш сбилженный сайт, но подменять в зависимости от запроса часть index.html.
Туториал
В первую очередь установим зависимости:
yarn add koa koa-static
Создаем файл entryServer.js. Из него мы будем отдавать наш сайт. В моем случае содержимое папки dist.
// entryServer.js
const Koa = require(‘koa’);
const fs = require(‘fs’);
const app = new Koa();
app.use(async (ctx, next) => {
const distHtml = fs.readFileSync(‘dist/index.html’, ‘utf8’);
ctx.body = distHtml;
});
const PORT = 3000;
console.log(`Listening on port ${PORT}`);
app.listen(PORT);
Если запустить node entryServer.js, то на https://localhost:3000 будет пустая страница. Это потому что все ассеты и скрипты недоступны, и сервер отдает вместо них index.html. Чтобы это исправить используем koa-static.
// entryServer.js
const Koa = require(‘koa’);
const fs = require(‘fs’);
const serve = require(‘koa-static’);
const app = new Koa();
app.use(async (ctx, next) => {
// Если запрашивается файл,
// то переходим к мидлваре,
// которая отдает статические
// ассеты
if (ctx.request.url.includes(‘.’)) {
await next();
return;
}
const distHtml = fs.readFileSync(‘dist/index.html’, ‘utf8’);
ctx.body = distHtml;
});
// Отдаем содержимое каталога dist
app.use(serve(‘dist’));
const PORT = 3000;
console.log(`Listening on port ${PORT}`);
app.listen(PORT);
Теперь наш сайт работает, как должен, но все еще только на клиенте. Давайте добавим логику на стороне сервера! Создадим несколько файлов в которых содержатся вариации SEO тегов для разных языков, например:
// entryServer.js
const Koa = require(‘koa’);
const fs = require(‘fs’);
const serve = require(‘koa-static’);
// Файлы, которые содержат только
// теги, которые мы собираемся локализовать.
//