Брендинг

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

Основная задача «Антифрода» — блокировать звонки и сообщения с подменных номеров, пресекая подозрительные вызовы еще до того, как мошенникам удастся дозвониться до человека. Система непрерывно собирает информацию о соединениях, номерах абонентов, включая те, что используются при переадресации, а также данные о дате и времени звонков, отправке СМС-сообщений и сетях связи, через которые проходила коммуникация.

Первым успешно протестировал функционал федеральной системы «Мегафон», а вслед за ним и «МТС» с «Вымпелкомом». «Теле2» и «Ростелеком» присоединились к системе в первом квартале 2023 года.

Очень скоро все федеральные и региональные операторы связи будут подключены к «Антифроду», и он охватит всю страну. На то есть одна веская причина — поправки в законодательство.

Почему операторы подключаются к системе «Антифрод»?

Необходимость пресекать неверифицированные телефонные вызовы была закреплена в законе «О связи» (№ 319-ФЗ) — часть 10 статьи 46. Штраф за пропуск таких вызовов составляет 500 тысяч рублей.

Чтобы понимать масштаб штрафов, достаточно посмотреть на статистику: в среднем в сутки по России сегодня осуществляется примерно 8,6 миллиона (!) мошеннических звонков. Если операторы начнут платить государству за каждый такой пропущенный вызов, общая сумма штрафов для отечественных операторов перевалит за 4 триллиона рублей в день. 

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

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

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

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

Как работает «Антифрод»

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

Во главе системы стоит Центральная система управления Главного радиочастотного центра (ГРЧЦ), который является частью Роскомнадзора. Именно эта структура представляет собой «мозг» всего «Антифрода». Она напрямую связана с узлами взаимодействия (УВз), к которым подключаются региональные операторы.

К узлам взаимодействия, а также напрямую к центральной системе подключаются узлы верификации. Они создаются и эксплуатируются самими операторами и являются точкой проверки для входящих и исходящих вызовов и сообщений. ГРЧЦ, в свою очередь, обслуживает эти узлы на удаленной основе, гарантируя их эффективную работу и надежность.

Крупные операторы связи подключаются к центральной системе ГРЧЦ напрямую без УВз и обмениваются с ней данными на постоянной основе. Есть в системе также и узлы верификации транзитных операторов, главная задача которых — отдавать ГРЧЦ историю вызовов, чтобы проводить анализ данных и улучшать «Антифрод». Вот как схематично должна работать система:

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

Роскомнадзор также будет отвечать за хранение и анализ информации о соединениях, которую получает от операторов связи. Она включает в себя данные о номерах абонентов, дате и времени вызовов и сообщений, а также сетях связи, задействованных в этих процессах. Таким образом каждый звонок с номера любого оператора можно будет верифицировать — и даже если вам позвонит «сотрудник банка», его можно будет найти и наказать по всей строгости закона. А подставить не свой номер телефона, у них просто нет возможности. Вызовы которые не будут проходить через ГРЧЦ будут блокироваться на сетях принимающего оператора и не доставляться до абонентского номера.

По той причине, что теперь на территории Российской Федерации есть работающий инструмент по выявлению и блокировке звонков с подменными номерами, то бизнесу открываются новые услуги. К примеру такая услуга как авторизация по звонку CallPasswordID, которая позволяет с помощью “Антифрод” системы верифицировать номера телефонов. Что можно применять в приложениях или на сайтах, для автоматизации проверки номеров своих клиентов на момент их регистрации или дальнейшей авторизации.

Зачем тестировщику DevTools и что с ним делать? Разбираем, как начать работу с инструментом, какие вкладки использовать, как назначить задачу для багфикса, чтобы разработчик был доволен. И ещё кое-что.

Всем привет! Меня зовут Дима, я Junior QA-инженер в РЕЛЭКС. А, точнее, ручной тестировщик веб-приложений. Инструмент DevTools, как его ещё называют — «консоль разработчика», плотно вошел в мою работу. Решил поделиться основными фичами, которые упростят жизнь тестировщику.

О чём внутри

Предыстория: зачем тестировщику DevTools и что с ним делать

Как тестировщику, DevTools полезен мне тем, что с ним могу проводить функциональное и UI-тестирование. При вызове функции в консоли увижу код ответа — станет понятно, корректно что-то работает или нет. Также смогу убедиться, соответствует ли интерфейс согласованным дизайн-макетам из документации, или размеры элементов интерфейса и шрифты реализованы с багами.

«Консолью разработчика» пользуются не только тестировщики, но и разработчики — логично из названия, да? 🙂 Для Frontend-разработчиков он служит для отладки UI (HTML, JavaScript, CSS) и для быстрого доступа к исходному коду сайта.

По сути, DevTools — это программы, позволяющие создавать, тестировать и отлаживать (debug) программное обеспечение. DevTools пользуются в основном веб-разработчики, т.к. для всех основных браузеров инструмент встроен и не нужно дополнительно что-то устанавливать и настраивать.

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

DevTools, выходи: клавиши для вызова

Начнем с комбинации клавиш для вызова DevTools в своём браузере. Если у вас Windows достаточно открыть браузер и нажать клавишу F12, если сидите с ПК. Чтобы вызвать с ноутбука, нажмите в любое место на странице правой кнопкой мыши > Просмотреть код. Либо просто можно зажать клавиши “Ctrl + Shift + I”.

Если у вас операционная система macOS, то чтобы вызвать DevTools нужно открыть браузер и зажать клавиши “cmd + Shift + I”. Либо нажмите в любое место на странице правой кнопкой мыши > Просмотреть код.

Как понять код ответа, что тестировщику с этим делать

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

1. Информационные. Код ответа от 100 до 199.

2. Успешные. Код ответа от 200 до 299.

3. Перенаправление. Код ответа от 300 до 399.

4. Клиентские ошибки. Код ответа от 400 до 499.

5. Серверные ошибки. Код ответа от 500 до 599.

Коротко о каждом ответе:

Код ответа 100 “Continue” — временный код ответа, означающий начало принятия запроса к его последующей обработке на сервере.

Код ответа 200 “OK” — означает, что обмен данными между клиентом и сервером прошел успешно. 

Код ответа 300 “Multiple Choices” — означает, что по указанному запросу существует несколько вариаций URL.

Код ответа 400 “Bad Request” — сигнализирует об ошибке, сервер не понял запрос пользователя из-за синтаксической ошибки.

Код ответа 500 “Internal Server Error” — значит, что произошла внутренняя ошибка сервера или возник его аварийный отказ.

Для тестировщика важно знать и понимать эти коды состояний — на каждую заведенную багу в баг-трекере к описанию нужно прикладывать скриншоты, где чётко видно код ответа на запрос. Часто тестировщик создает задачи для фикса, когда видит 400 и 500 коды ответов.

Это база: четыре основные вкладки DevTools для ежедневной работы 1. Вкладка “Network”

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

Что ещё можно делать: мониторить коды ответов, типы запросов, «тяжесть» передаваемых запросов и скорость их обработки. Также можно провалиться в любой запрос и просмотреть данные, которые передает разработчик внутренней архитектуры на фронтальную часть приложения. Например, API конкретного запроса.

Здесь же полезная опциональная функция для симуляции скорости интернета — 3G, 4G. Можно выставлять скорость вручную или создать ситуацию, когда у приложения пропадает доступ к интернету. Так проверяем быстроту обработки запросов на разной скорости интернета, а также оцениваем поведение системы, если интернет пропал.

В этой вкладке есть вспомогательные инструменты для фильтрации запросов (Fetch/XHR, Img, JS и т.д.). С кнопкой “Clear network log” очищаем все ранее отправленные запросы, если нужно выловить какой-то один. Кнопка “Stop recording network log” для стопа отображения новых запросов. “Search” — поиск конкретного запроса.

2️. Вкладка “Console”

Здесь обычно отсматриваю ошибки, которые падают в системе при её использовании. Ошибки отображаются как количественно, так и списком. Для удобства в некоторые ошибки можно провалиться и прочесть, чем она вызвана — поможет собрать более подробную информацию для багфикса.

3️. Вкладка “Elements”

В этой вкладке представлен конечный код HTML-страницы, который отличается от исходного. Тестировщик может вручную изменять его: корректировать размеры элементов, включать и выключать стили, менять цвета и т.д. Так сказать, почувствовать себя Frontend-разработчиком. Правда, все эти изменения проходят в рамках задач тестирования и никак не повлияют на конечный код, так как мы работаем в DevTools.

4. Вкладка “Application”

Здесь можно детально ознакомиться с Cookies. Посмотреть refreshToken и accessToken — полезны тестировщику для дальнейшего тестирования Backend-части приложения с помощью Postman (сервис для создания, тестирования, документирования, публикации и обслуживания API). Без этих токенов не получится авторизоваться и «подергать» нужные API.

Назначаем задачу для багфикса правильно: какие скриншоты из DevTools приложить

Во вкладке “Network”, можно провалиться в любой запрос для получения более подробной информации. Например, я прикладываю скриншот из подвкладки “Headers”, чтобы разработчик сразу увидел код ошибки. Подвкладка “Headers” автоматически будет открыта, если нажмёте на сам запрос в “Network”.

В подвкладке “Payload” можно посмотреть Body самого запроса. А в “Preview”, какое сообщение об ошибке нам выдает система.

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

Если непонятно, проблема на Backend-стороне или Frontend, в DevTools можно посмотреть всю информацию и назначить задачу для багфикса. По возможности прикладывайте скриншоты и с веба, и с DevTools — разработчики это оценят.

Можно ли тестировать мобилку в консоли разработчика? Спойлер: можно

Для этого есть встроенный инструмент “Toggle device toolbar”. Помогает протестировать отображение интерфейса для разных устройств и разных размеров экранов.

При тестировании можно выставить модель телефона — интерфейс веб-приложения адаптируется под мобильную версию экрана нужной модели. Также любой размер экрана можно выставить вручную. Есть возможность менять ориентацию для устройств (горизонтально, вертикально) или изменять значение заряда батареи (заряжен наполовину, мало зарядки, разрядился).

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

А вот если вы изначально тестировщик мобилки, то полное тестирование интерфейса в “Toggle device toolbar” без рабочих портативных устройств — плохая затея. Рискуете пропустить большое количество багов.

Инструменты для тестирования UI-приложения

Здесь часто использую инструмент “Select an element in the page to inspect it”. Помогает протестировать интерфейс приложения в соответствии с макетами UX/UI-дизайнера. Удобно проверять все макеты из Figma. При наведении на элемент интерфейса сразу отображается его размер, название цвета и т.д.

Также рекомендую вкладку “Elements”. Для примера показал, как в 2 клика здесь можно изменить цвет кнопки.

Прощаемся

Перечислил в статье основные вкладки и инструменты, полезные ручному тестировщику при проверке веб-приложений. Спасибо, если дочитали до конца!

В последнее время наблюдается стремительный прогресс в сфере обработки естественного языка. Появление мощных языковых моделей вроде GPT и Bard действительно открыло новые возможности для создания интеллектуальных приложений. Однако вместе с тем мы столкнулись с необходимостью более совершенных инструментов для эффективной интеграции и управления такими моделями.

И вот недавно компания Microsoft представила Guidance – язык управления, предназначенный для контроля над большими языковыми моделями. По нашему мнению, этот инструмент может существенно изменить процесс разработки приложений на основе возможностей AI. 

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

Приглашаем к прочтению! 

Сразу к сути

Когда в нашей компании мы начали тестировать Guidance, это был действительно положительный опыт. 

Во-первых, нам понравился специальный синтаксис Guidance, основанный на handlebars, для пошагового описания обработки данных языковой моделью.

Благодаря этому код Guidance выполняется последовательно, отражая порядок анализа входного текста моделью. Это дало нам возможность точно контролировать процесс генерации текста.

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

Кроме того, генерация за один проход в Guidance экономит вычислительные ресурсы по сравнению с многократным обращением к модели. Он может быть легко интегрирован с такими провайдерами, как модели Hugging Face, и включает в себя интеллектуальную систему кэширования генерации на основе семплов и систему token healing, которая оптимизирует границы подсказок и устраняет смещение при токенизации. Включение направляющих шаблонов regex дополнительно обеспечивает соблюдение форматов, позволяя естественным образом завершать подсказки.

Еще одна полезная особенность Guidance – это поддержка конструкций выбора при генерации текста. Это позволило нам описывать разветвленную логику работы приложения. Например, можно представить возможность выбора из нескольких вариантов, как в примере:

{{#select “answer”}}

Yes

{{or}}

No

{{/select}}

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

Кроме того, большим плюсом Guidance является возможность подключения разных языковых моделей, а не только конкретных решений вроде GPT-3 или Codex. Подключение происходит не через API, а с помощью встроенных трансформеров, как в примере для self-hosted модели Facebook LLaMA:

llm = guidance.llms.Transformers(“your_local_path/llama-7b”, device=0)

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

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

А что такого в Guidance?

Когда наша команда разработчиков приступила к изучению Guidance, мы были приятно удивлены обилием полезных и интересных фишек.

Про token healing мы уже упоминали выше, но хочется остановиться на этом подробнее.
В процессе создания языковых моделей часто используются стандартные “жадные” токенизаторы. К сожалению, они вносят скрытое, но достаточно сильное искажение, которое может приводить к непредсказуемому поведению LLM.

Давайте разберёмся на конкретном примере из документации на GitHub. Представим, что мы пытаемся сгенерировать URL-строку:

# Мы используем StableLM как открытый пример, но эти проблемы затрагивают все модели в той или иной степени

guidance.llm = guidance.llms.Transformers(“stabilityai/stablelm-base-alpha-3b”, device=0)

 # Мы отключаем token healing, чтобы guidance вела себя как обычная библиотека подсказок

program = guidance(”’Ссылка:

program()

Заметим странность: вместо ожидаемого http:// модель возвращает что-то вроде http: /. Причина в том, что токенизатор разбивает строку :// на отдельные символы. Увидев :, модель решает, что // тут быть не может, иначе использовался бы целый токен ://.

Это не ограничивается только двоеточием, такая ситуация встречается практически повсеместно. Более 70% распространённых токенов являются префиксами более длинных токенов. Это приводит к ошибкам на границах токенов.

В Guidance это решается с помощью token healing. Эта техника откатывает модель на шаг назад, а затем разрешает модели двигаться вперёд, ограничивая её генерацией только тех токенов, префикс которых совпадает с последним токеном. Это исключает искажение токенизатора и позволяет завершить промпт естественным образом.

prompt=”Ссылка:

output = model(prompt)  

# теперь корректно сгенерирует http://

Еще один большой плюс для нас как разработчиков – удобные средства отладки кода. Особенно нам пригодилась реализованная в Guidance функция “пошагового выполнения”. Она позволила детально анализировать выполнение каждой строки и оптимизировать логику приложения.

В целом, уникальные возможности Guidance позволяют нам максимально раскрыть потенциал языковых моделей ИИ для создания по-настоящему сложных и интересных решений.

А что еще?

По мере изучения Guidance, мы все больше осознавали полезность возможностей этого инструмента.

Во-первых, на практике мы убедились, что с Guidance можно добиться намного более точной генерации текста, чем с традиционными методами. За счет пошагового выполнения удается тонко контролировать весь процесс. 

Еще одна крутая штука – это вызов функций. Можно вызывать любые функции Python, используя сгенерированные переменные в качестве аргументов. Функция будет вызвана при выполнении подсказки:

“`python

def aggregate(best):

  return ‘n’.join()

prompt = guidance(”’Лучшее на пляже – это {{~gen ‘best’ n=3 temperature=0.7 max_tokens=7 hidden=True}}  

{{aggregate best}}”’)

prompt = prompt(aggregate=aggregate)

print(prompt)

“`

Таким образом, можно использовать любые функции Python внутри подсказок Guidance, вызывая их с аргументами, сгенерированными моделью. Это расширяет возможности построения подсказок.

Кроме текстов, Guidance позволяет удобно работать с самыми разными данными – создавать таблицы, генерировать отчёты в нужном формате. При этом выходные данные всегда получаются валидными. Например, JSON-данные корректно отформатируются даже при использовании сложных вложенных структур. То же самое касается XML, CSV и других форматов.

Итоги

После изрядного времени, потраченного на тестирование Guidance, мы можем сделать следующие выводы. Этот инструмент действительно предлагает новый подход к созданию приложений на основе ИИ.

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

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

По нашему мнению, Guidance может заинтересовать многие IT-компании и стартапы благодаря такой доступности технологии. Уверены, на его основе вскоре появится немало инновационных продуктов.

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

Данный материал – перевод статьи https://kilianvalkhof.com/2017/design/sloped-edges-with-consistent-angle-in-css/. Мне, как начинающему forntend-разработчику, этот материал был интересен. Полагаю, эта статья будет полезна и другим начинающим или обучающимся фронтендерам.

Хедер оригинальной статьи

Если вы посмотрите выше, то увидите, что хедер этого блога имеет наклонный край. Это одна из моих любимых особенностей нового дизайна. Техника, которую я использовал, обеспечивает постоянный угол наклона независимо от размера экрана, позволяет показывать фоновые изображения и использует только один HTML-элемент без псевдоэлементов. Вот как я это сделал.

Требования

Было несколько требований, предъявляемых к реализации:

• Внешний вид не зависит от размера экрана.

• Поддержка (и правильная фиксация) фоновых изображений и текста на переднем плане.

• Работа на разных устройствах (не слишком заботясь об IE).

Если я также смогу максимально упростить HTML и CSS, то это будет бонусом, но не требованием.

Первоначальная идея

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

header {
width:100%;
transform:rotate(2deg);
}

Применение трансформации вращения к элементу

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

header {
width:110%;
top:-5%;
left:-5%;
transform:rotate(2deg);
}

Увеличение внутреннего элемента

Затем добавим к странице или дополнительному элементу параметр overflow:hidden;, чтобы не возникало странных горизонтальных полос прокрутки:

body {
overflow:hidden;
}

header {
width:110%;
top:-5%;
left:-5%;
transform:rotate(2deg);
}

Применение overflow: hidden;

Это выглядит замечательно, но что, если добавить туда текст?

Добавление текста

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

body {
overflow:hidden;
}

header {
width:110%;
top:-5%;
left:-5%;
transform:rotate(2deg);
}

header p {
margin-left:5%;
transform:rotate(-2deg);
}

Поворот и смещение текста

До сих пор все работает нормально. Проблема начинается при переходе от фиксированной ширины к отзывчивой (responsive). Вот тот же элемент, только более широкий:

Масштабирование страницы

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

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

Псевдоэлемент ::after

Другой часто используемой техникой является добавление преобразования к псевдоэлементу ::after, а не к самому элементу. Это имеет ряд преимуществ по сравнению с приведенным выше кодом:

• Есть уверенность в том, что страница не будет выходить за левый или правый верхний угол.

• Нет необходимости поворачивать содержимое в обратную сторону.

Так что давайте попробуем:

header::after {
position:absolute;
content: ” “;
display:block;
left:-5%;
bottom:-10px;
transform:rotate(2deg);
width:110%;
}

Добавление псевдоэлемента ::after

(полупрозрачность наложена с перекрытием, так что видно, где находятся элементы) Это работает, но нужно сместить элемент ::after так, чтобы он полностью перекрывал нижний край, и, как в примерах выше, также нужно сделать его немного шире, чтобы не было видно краев слева или справа. Я отключил overflow:hidden; и можно увидеть как располагается элемент ::after.

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

Псевдоэлемент ::after с границей

В CSS можно использовать комбинацию видимых и прозрачных границ, чтобы получить видимые треугольники, которые могут заменить наклонный край. Попробуем использовать ::after с наклонной границей:

Использование ::after с наклонной границей

Выглядит хорошо, имеет гораздо лучшее сглаживание и работает, если сделать ширину тоже больше (при условии, что вы используете относительный размер для ширины границы):

Использование ::after с наклонной границей при увеличении ширины

Вместо границы, в другой технике, которую я видел, в качестве фонового изображения элемента ::afterиспользуется SVG с шириной и высотой в 100%, что приводит к тому же результату.

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

• Еще один абсолютно позиционируемый элемент, который необходимо иметь в виду.

• Трудно контролировать нужный угол и сохранять его.

• Вы ограничены использованием сплошных фоновых цветов.

До этого момента ни один из моих примеров не демонстрировал использование фоновых изображений (это достаточно сложно само по себе), но фоновое изображение было тем, что я действительно хотел видеть в хедере и футере. Псевдоэлементы ::after вообще не поддерживают этот эффект. Трансформированный хедер также создаст дополнительные проблемы при позиционировании фона.

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

Использование Clip-Path

Если убрать трансформации и границы ::after , останется clip-path.

Clip-path не очень хорошо поддерживается, только браузеры с Webkit, Blink и Gecko поддерживают его, а для последнего необходим SVG-элемент. К счастью для меня, я могу пренебречь этим в моем личном блоге. Это Clip Path!

Добавление clip-path не представляет сложности: с помощью функции polygon можно описать трапецию следующим образом:

header {
clip-path: polygon(
0 0, /* left top */
100% 0, /* right top */
100% 100%, /* right bottom */
0 90% /* left bottom */
);
}

Использование функции polygon

И это работает великолепно! Он работает так, как не работали методы transform и border. Можно добавить фоновое изображение, с наложением не происходит ничего курьезного, край резкий, и нужен всего один элемент

В современном мире, где данные играют ключевую роль в принятии решений, мобильные центры принятия решений (ЦПР) становятся все более популярными. Мобильные ЦПР предоставляют возможность пользователю получать актуальную информацию и аналитику в режиме реального времени, что позволяет принимать обоснованные решения на основе данных. В этой статье мы рассмотрим ключевые шаги начала разработки мобильного ЦПР, которые позволят успешно создать инструмент для оперативного и обоснованного принятия решений.

1. Подготовительные этапы

Первым шагом в разработке мобильного ЦПР является проведение исследования бизнес-потребностей. Необходимо проанализировать существующие проблемы и узкие места, которые могут быть решены с помощью мобильного ЦПР. Это позволит определить ключевые бизнес-показатели и данные, которые необходимо мониторить для принятия решений.

1.1. Определение функциональности

После исследования бизнес-потребностей необходимо определить функциональность мобильного ЦПР. Составление списка необходимых функций и возможностей поможет определить, какие данные и аналитика должны быть доступны пользователю. Также необходимо учесть требования пользователей и целевой аудитории, чтобы разработать мобильное ЦПР, которое будет удобным и понятным для пользователей.

1.2. Техническое планирование1.2.1. Выбор платформы

Выбор платформы – важный шаг, который определит, на каких устройствах и операционных системах будет работать мобильный ЦПР. Это может быть iOS, Android или использование кроссплатформенных инструментов для расширения охвата аудитории.

1.2.2. Выбор языка программирования и технологий

Выбор языка программирования и технологий зависит от платформы и требований проекта. Например, для разработки под iOS может быть использован Swift, а для Android – Kotlin. Также важно выбрать подходящие инструменты для работы с данными и аналитикой.

1.2.3. Оценка интеграции с существующими системами и базами данных

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

2. Разработка и дизайн2.1 Создание прототипа и макета интерфейса2.1.1. Проработка пользовательского опыта (UX)

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

2.1.2. Визуальное оформление и дизайн интерфейса (UI)

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

2.2 Разработка функциональности2.2.1 Реализация ключевых функций приложения

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

2.2.2 Интеграция с источниками данных и аналитикой

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

2.2.3 Разработка механизмов принятия решений на основе данных

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

2.3 Тестирование и отладка

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

3. Разворачивание и внедрение3.1. Выбор стратегии внедрения

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

3.2. Подготовка инфраструктуры3.2.1 Развертывание серверов и хранилищ данных

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

3.2.2 Обеспечение безопасности передачи и хранения данных

Безопасность данных — приоритетная задача при развертывании мобильного ЦПР. Необходимо принять меры для защиты данных от несанкционированного доступа и обеспечения безопасности передачи информации между клиентскими устройствами и серверами.

3.3. Обучение пользователей3.3.1 Проведение обучающих сессий и вебинаров

Обучение пользователей — ключевой аспект успешного внедрения мобильного ЦПР. Проведение обучающих сессий и вебинаров позволяет пользователям овладеть функциональностью приложения и научиться эффективно использовать его в повседневной работе.

3.3.2 Создание руководств пользователя

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

4. Масштабирование и поддержка 4.1. Мониторинг и анализ использования4.1.1. Сбор данных об использовании и эффективности

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

4.1.2. Анализ обратной связи от пользователей

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

4.2. Постоянное усовершенствование

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

Мир бизнеса постоянно меняется, и мобильный ЦПР должен быть готов к новым вызовам. Итеративное развитие позволяет постепенно совершенствовать функциональность и интерфейс приложения, делая его более удобным и эффективным для пользователей.

4.3. Поддержка пользователей

Команда разработки и поддержки должна быть готова быстро реагировать на запросы пользователей и обратную связь. Это помогает поддерживать позитивный опыт использования приложения и решать возникающие проблемы.

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

5. Завершающий этап

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

1. Подведение итогов разработки мобильного ЦПР: необходимо оценить, насколько успешно были выполнены все шаги разработки и достигнуты поставленные цели.

2. Успехи и достижения при использовании мобильного ЦПР: нужно описать успехи и достижения, которые были получены при использовании мобильного ЦПР. Это может быть связано с улучшением процессов принятия решений, повышением эффективности бизнеса или другими положительными результатами.

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

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

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

Типичные проблемы с аналитикой для бизнесаСбои в работе аналитических платформ

Один из наиболее распространенных недостатков – это сбои в работе аналитических платформ и BI-решений. Пользователи могут столкнуться с зависаниями, недоступностью системы или медленной производительностью. Это может быть вызвано различными факторами, включая программные баги, недостаточные ресурсы или неправильную настройку.

Проблемы с данными и источниками данных

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

Недостаточная безопасность данных

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

Неэффективные дашборды и отчеты

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

Неадекватная мобильная поддержка

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

Анализ причин проблем

Теперь давайте рассмотрим причины, по которым возникают эти проблемы в аналитике для бизнеса.

Программные баги и ошибки

Один из основных источников проблем – это программные баги и ошибки в аналитических приложениях. Даже небольшие ошибки могут привести к сбоям и неправильным результатам.

Проблемы с данными и источниками данных

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

Безопасность данных

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

Неэффективное проектирование дашбордов и отчетов

Неудачное проектирование дашбордов может затруднять понимание информации и принятие решений.

Неоптимизированные мобильные приложения

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

Диагностика и тестирование

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

Анализ данных и отладка

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

Тестирование источников данных

Проверьте качество и актуальность данных, поступающих в систему аналитики. Убедитесь, что данные соответствуют ожиданиям.

Проверка безопасности

Проведите аудит безопасности, чтобы выявить уязвимости и принять меры по их устранению.

Оценка дизайна дашбордов и отчетов

Проверьте дизайн дашбордов и отчетов на предмет удобства использования и информативности.

Тестирование мобильных приложений

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

Решения для устранения проблем

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

Исправление программных багов

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

Обновление источников данных

Улучшите процесс сбора и интеграции данных, чтобы гарантировать их точность и актуальность.

Улучшение безопасности данных

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

Оптимизация дашбордов и отчетов

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

Оптимизация мобильных приложений

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

Мониторинг и предупреждение

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

Мониторинг производительности

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

Мониторинг безопасности

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

Автоматическое оповещение

Настройте автоматическое оповещение о критических проблемах, чтобы оперативно реагировать и устранять их.

Примеры успешного устранения проблем

Давайте рассмотрим несколько примеров успешного устранения проблем в области аналитики для бизнеса:

Netflix: Оптимизация производительности мобильного приложения

Проблема: Netflix столкнулся с проблемой низкой производительности своего мобильного приложения на некоторых устройствах. Это приводило к долгой загрузке видео и неудовлетворенности пользователей.

Решение: Команда разработчиков провела глубокий анализ кода приложения и выявила узкие места. Они оптимизировали алгоритмы потоковой передачи, уменьшили использование ресурсов и улучшили механизмы кэширования. В результате производительность мобильного приложения заметно увеличилась, и пользователи получили более быстрый и плавный просмотр контента.

Salesforce: Улучшение безопасности данных

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

Решение: Компания немедленно усилила систему безопасности, внедрив двухфакторную аутентификацию, мониторинг угроз и усовершенствованную систему ролевых прав доступа. Эти меры существенно повысили безопасность данных и уверенность клиентов в сохранности их информации.

Amazon: Оптимизация обработки данных в реальном времени

Проблема: Amazon столкнулся с тем, что обработка больших объемов данных в реальном времени была медленной, что замедляло принятие стратегических решений в электронной коммерции.

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

Microsoft: Устранение дубликатов данных

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

Решение: Компания внедрила систему мастер-данных (Master Data Management), которая автоматически идентифицировала и устраняла дубликаты данных. Это позволило улучшить точность данных и обеспечить единое представление о клиентах и продуктах.

Google: Улучшение дизайна дашбордов

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

Решение: Команда дизайнеров и аналитиков провела исследование пользователей и пересмотрела дизайн дашбордов, сделав их более интуитивными и информативными. Это улучшило процесс анализа данных и увеличило эффективность работы аналитических команд.

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

Заключение

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

Предлагается перевод книги Vue.js 3 Design Patterns and Best Practices автора Pablo Garaguso.

Книга вышла в мае 2023 года, написана очень компетентно, оперирует современными технологиями и стандартами. Материал книги будет полезен разработчикам не только Vue, но и других фронтенд фреймворков.

Саму книгу можно приобрести в издательстве O’Reilly

Краткое содержание:

Глава 1, Фреймворк Vue 3

Что представляет собой прогрессивный фреймворк Vue 3? В этой главе представлены наиболее важные аспекты фреймворка и другие ключевые понятия.

Глава 2, Принципы и шаблоны проектирования программного обеспечения

Принципы и шаблоны проектирования программного обеспечения являются визитной карточкой хорошей архитектуры программного обеспечения архитектуры. В этой главе рассказывается о них, приводятся примеры для реализации на JavaScript и Vue 3.

Глава 3, Создание рабочего проекта

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

Глава 4, Композиция пользовательского интерфейса с помощью компонентов

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

Глава 5, Одностраничные приложения

Это ключевая глава, в которой представлен маршрутизатор Vue Router для создания **одностраничных** веб-приложений.

Глава 6, Прогрессивные веб-приложения

В этой главе на основе **SPA** создаются **PWA**, а также представлены инструменты для оценки их полноты и производительности.

Глава 7, Управление потоками данных

Эта глава знакомит с ключевыми концепциями проектирования и управления потоками данных и информации в приложении. В ней представлена Pinia как официальный фреймворк управления состояниями для Vue 3.

Глава 8, Многопоточность с помощью web-workers

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

Глава 9, Тестирование и контроль исходных текстов

В этой главе мы знакомимся с официальными инструментами тестирования предоставляемыми командой Vue, а также с наиболее распространенной системой контроля версий: Git. В главе показано, как создавать тестовые примеры для кода на JavaScript, а также компонентов Vue 3.

Глава 10, Развертывание приложения

В этой главе представлены концепции, необходимые для понимания того, как опубликовать приложение Vue 3 на живом рабочем сервере и как защитить его с помощью Let’s Encrypt.

Глава 11, UX Patterns

Эта бонусная глава расширяет понятия пользовательского интерфейса и паттернов пользовательского опыта, чтобы обеспечить общий язык между разработчиком и дизайнером. В ней представлены общие шаблоны, предусмотренные стандартом HTML 5, и другие общие элементы.

Приложение: Миграция с Vue 2 на Vue 3

В этом приложении представлено руководство по изменениям и вариантам миграции для опытных разработчиков Vue 2.

——

На данный момент переведено две первые главы
Ссылка на перевод книги

Привет! В этой статье мы разберемся, как отправлять push-уведомления пользователям iOS, даже если ваше приложение временно недоступно в App Store. С выходом Safari 16.4, появилась возможность получать уведомления в Progressive Web Apps (PWA)

Давайте разберем эту задачу со строны фронтенд‑разработчика

Что нам понадобится

Серверная часть: для серверной логики выберем Node.js.

Клиентская часть: мы будем использовать React.js для создания пользовательского интерфейса.

Push-сервис: в качестве сервиса для отправки push-уведомлений используем Google Cloud Messaging.

Взаимодействие сервисов

Создание сервера на Express.js

Давайте начнем с создания VAPID ключей. Чтобы понять, зачем они нужны, кратко пройдемся по теории. VAPID — это, по сути, уникальный ID для вашего приложения в мире веб-пуш-уведомлений. Эти ключи помогут браузеру понять, откуда идет уведомление, и обеспечат дополнительный слой безопасности. Итак, у нас будет пара ключей публичный и приватный

Теперь практика! Мы будем использовать библиотеку для Node.js под названием web-push. Эта библиотека хорошо работает с Google Cloud Messaging, системой от Google для отправки уведомлений

Устанавливаем библиотеку c помощью npm

npm install web-push -g

Генерируем ключи

web-push generate-vapid-keys

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

Приватный ключ будет храниться на нашем сервере. Он нужен для подписи данных, которые мы отправляем, и для проверки подлинности нашего приложения перед системами отправки уведомлений, такими как Google Cloud Messaging.

Создадим два url-адреса: один для сохранения подписок на уведомления, а другой для их отправки.

// Подключаем библиотеку web-push для работы с push-уведомлениями
const webPush = require(‘web-push’);

webPush.setVapidDetails(
publicKey,
privateKey
);

// Инициализация объекта для хранения подписок
let subscriptions = {}

// Роут для подписки на push-уведомления
app.post(‘/subscribe’, (req, res) => {
// Извлекаем подписку и ID из запроса
const {subscription, id} = req.body;
// Сохраняем подписку в объекте под ключом ID
subscriptions = subscription;
// Возвращаем успешный статус
return res.status(201).json({data: {success: true}});
});

// Роут для отправки push-уведомлений
app.post(‘/send’, (req, res) => {
// Извлекаем сообщение, заголовок и ID из запроса
const {message, title, id} = req.body;
// Находим подписку по ID
const subscription = subscriptions;
// Формируем payload для push-уведомления
const payload = JSON.stringify({ title, message });

// Отправляем push-уведомление
webPush.sendNotification(subscription, payload)
.catch(error => {
// В случае ошибки возвращаем статус 400
return res.status(400).json({data: {success: false}});
})
.then((value) => {
// В случае успешной отправки возвращаем статус 201
return res.status(201).json({data: {success: true}});
});
});Настройка клиентской части

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

// Функция для преобразования Base64URL в Uint8Array
const urlBase64ToUint8Array = (base64String) => {
const padding = ‘=’.repeat((4 – base64String.length % 4) % 4);
const base64 = (base64String + padding)
.replace(/-/g, ‘+’)
.replace(/_/g, ‘/’);

const rawData = window.atob(base64);
const outputArray = new Uint8Array(rawData.length);

for (let i = 0; i < rawData.length; ++i) { outputArray = rawData.charCodeAt(i); } return outputArray; }; // Хук для подписки на push-уведомления const useSubscribe = ({ publicKey }) => {
const getSubscription = async () => {
// Проверка поддержки ServiceWorker и PushManager
if (!(‘serviceWorker’ in navigator) || !(‘PushManager’ in window)) {
throw { errorCode: “ServiceWorkerAndPushManagerNotSupported” };
}

// Ожидание готовности Service Worker
const registration = await navigator.serviceWorker.ready;

// Проверка наличия pushManager в регистрации
if (!registration.pushManager) {
throw { errorCode: “PushManagerUnavailable” };
}

// Проверка на наличие существующей подписки
const existingSubscription = await registration.pushManager.getSubscription();

if (existingSubscription) {
throw { errorCode: “ExistingSubscription” };
}

// Преобразование VAPID-ключа для использования в подписке
const convertedVapidKey = urlBase64ToUint8Array(publicKey);
return await registration.pushManager.subscribe({
applicationServerKey: convertedVapidKey,
userVisibleOnly: true,
});
};

return {getSubscription};
};

Пример использования React хука для получения объекта подписки и отправки его на сервер

// Импорт функции useSubscribe и задание публичного ключа (PUBLIC_KEY)
const { getSubscription } = useSubscribe({publicKey: PUBLIC_KEY});

// Обработчик для подписки на push-уведомления
const onSubmitSubscribe = async (e) => {
try {
// Получение объекта подписки с использованием функции getSubscription
const subscription = await getSubscription();

// Отправка объекта подписки и ID на сервер для регистрации подписки
await axios.post(‘/api/subscribe’, {
subscription: subscription,
id: subscribeId
});

// Вывод сообщения в случае успешной подписки
console.log(‘Subscribe success’);
} catch (e) {
// Вывод предупреждения в случае возникновения ошибки
console.warn(e);
}
};

Так большую часть мы уже успешно сделали, теперь нам нужно отобразить уведомление, которое прилетит от Google Cloud Messaging.

Push-уведомления

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

Сервис-воркер — это фоновый скрипт, работающий независимо от основного потока веб-приложения. Этот скрипт предоставляет возможность обрабатывать сетевые запросы, кешировать данные и в нашем случае — прослушивать входящие push-уведомления

Push API — это веб API, которое позволяет серверам отправлять информацию напрямую к браузеру пользователя.

Пример service-worker.js

// Добавляем слушателя события ‘push’ к сервис-воркеру.
self.addEventListener(‘push’, function(event) {
// Извлекаем данные из push-события
const data = event.data.json();

// Опции для уведомления
const options = {
// Текст сообщения в уведомлении
body: data.message,
// Иконка, отображаемая в уведомлении
icon: ‘icons/icon-72×72.png’
};

// Используем waitUntil для того, чтобы удерживать сервис-воркер активным
// пока не будет показано уведомление
event.waitUntil(
self.registration.showNotification(data.title, options)
);
});Демо

Для возможности проверки на собственном устройстве вот ссылка на тестовый стенд. Для более подробного изучения кода оставляю ссылку на GitHub репозиторий.

Благодарю за внимание 🙂

Приветствую! В ходе своей профессиональной деятельности, каждый фронтенд-разработчик сталкивается с неотъемлемой частью разработки – инструментом ESLint. ESLint представляет собой мощный статический анализатор кода, призванный обнаруживать и устранять проблемы в вашем JavaScript коде.

Сегодня мы поговорим, о настройке shareable config. Мы рассмотрим, как это может помочь продуктовым командам или фрилансеру разработчику, а далее перейдем к настройке этой конфигурации.

Shareable Config: Когда это надо?

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

После того как были согласованы наборы правил, назначены ответственные за их реализацию и настройку, начинается этап реализации в проектах. Однако, при возникновении необходимости внести изменения в конфигурацию ESLint, многократное редактирование всех проектов может быть трудозатратным и неэффективным. Именно в таких ситуациях на помощь приходит создание Shareable config для ESLint и его последующая публикация в репозитории пакетов, таких как npm или других пакетных реестрах

Преимущества создания и использования Shareable config:

1. Единое правило: Создавая Shareable config, вы устанавливаете единый набор правил для всех проектов. Это обеспечивает согласованный стиль кода и снижает вероятность возникновения ошибок, связанных с разнообразными конфигурациями.

2. Централизованное управление: Если вам необходимо внести изменения в правила ESLint, вы можете внести их в Shareable config, и эти изменения автоматически применятся ко всем проектам, использующим эту конфигурацию. Это значительно упрощает управление и поддержку кодовой базы.

3. Снижение затрат: Вместо того чтобы править конфигурации в каждом проекте, вы вносите изменения только в Shareable config и публикуете его. Это экономит время и уменьшает затраты на обслуживание.

4. Публичная доступность: Публикация Shareable config в пакетном реестре позволяет другим командам и разработчикам использовать вашу конфигурацию. Это способствует распространению фронтенд стандартов и позволяет другим внедрять их в свои проекты.

Инициализация конфигурации проекта

Давайте создадим папку eslint-config-test и создадим модуль с ограниченной областью действия. Используем команду npm init –scope=@test и пройдемся по шагам установки.

В итоге мы получим файл, на основе этого:

{
  “name”: “@test/eslint-config-test”,
  “version”: “1.0.0”,
  “description”: “ESLint Shareable Config”,
  “main”: “main.js”,
  “scripts”: {
    “test”: “echo “Error: no test specified” && exit 1″
  },
  “keywords”: ,
  “author”: “Kim Valentin”,
  “license”: “ISC”
}

Здесь важно отметить @test – scope npm модуля, более подробно в документации

Сюда по степени необходимости можно добавить еще несколько опциональных свойств: “files”, “repositry”,“bugs”, “dependencies”, “devDependencies”, “peerDependencies” и другие. О каждом более подробно можно узнать в документации

Я добавил пару пакетов для работы конфига (их не нужно будет ставить в основном проекте, кроме peerDependencies):

“dependencies”: {
“@typescript-eslint/eslint-plugin”: “^6.7.2”,
“@typescript-eslint/parser”: “^6.7.2”,
“@vue/eslint-config-typescript”: “^12.0.0”,
“eslint-config-airbnb-base”: “^15.0.0”,
“eslint-plugin-import”: “^2.28.1”,
“eslint-plugin-vue”: “^9.17.0”
},
“devDependencies”: {
“eslint”: “^8.50.0”,
“typescript”: “~5.2.2”
},
“peerDependencies”: {
“eslint”: “>= 8.50.0”,
“typescript”: “>= 5.0.0”
}
Создание модуля конфигурация

Здесь все достаточно просто мы создаем модуль для будущего использования с расширением .js. Например, у меня вышел такой модуль:

module.exports = {
root: true,

env: {
es6: true,
browser: true,
node: true,
},

extends: ,

parserOptions: {
parser: require.resolve(‘@typescript-eslint/parser’),
extraFileExtensions: ,
ecmaVersion: ‘latest’,
sourceType: “module”,
ecmaFeatures: {
jsx: true,
},
},

globals: {
JSX: true,
},

plugins: ,

rules: {
semi: ,
‘no-param-reassign’: ‘off’,
‘no-void’: ‘off’,
‘no-nested-ternary’: ‘off’,
‘max-classes-per-file’: ‘off’,
‘linebreak-style’: 0, // ignore linebreak-style
‘no-plusplus’: ‘off’,
‘max-len’: ,
‘vue/block-order’: , ‘style’ ] }],
‘no-use-before-define’: ‘off’,
‘@typescript-eslint/no-use-before-define’: ,
‘no-underscore-dangle’: ‘off’,
‘no-shadow’: 0,
‘@typescript-eslint/no-shadow’: 0,
‘new-cap’: ,
‘import/first’: ‘off’,
‘import/named’: ‘error’,
‘import/namespace’: ‘error’,
‘import/default’: ‘error’,
‘import/export’: ‘error’,
‘import/extensions’: ‘off’,
‘import/no-unresolved’: ‘off’,
‘import/no-extraneous-dependencies’: ‘off’,
‘import/prefer-default-export’: ‘off’,

// ‘prefer-promise-reject-errors’: ‘off’,

quotes: ,

// this rule, if on, would require explicit return type on the `render` function
‘@typescript-eslint/explicit-function-return-type’: ‘off’,

// in plain CommonJS modules, you can’t use `import foo = require(‘foo’)` to pass this rule, so it has to be disabled
‘@typescript-eslint/no-var-requires’: ‘off’,

// The core ‘no-unused-vars’ rules (in the eslint:recommended ruleset)
// does not work with type definitions
‘no-unused-vars’: ‘off’,

// allow debugger during development only
‘no-debugger’: process.env.NODE_ENV === ‘production’ ? ‘error’ : ‘off’,
‘@typescript-eslint/member-delimiter-style’: ,
‘@typescript-eslint/no-explicit-any’: ‘warn’,
},
}
Публикация пакета

Пару шагов и мы создали с вами наш конфиг. Далее мы можем опубликовать пакет в npm или package registry Gitlab. Настроить CI и использовать.

P.S. Если вы решили использовать package registry Gitlab, у вас будет несколько вариантов, либо настроить publishConfig в package.json и ssh ключ в CI. Либо использовать такую конструкцию:

“devDependencies”: {
“@test/eslint-config-test”: “git+ssh://user@host/path/eslint-config-test#branch”
}
Использование пакета

Необходимо на проекте установить нужные зависимости (peerDependencies). Далее можно создать файл .eslintrc.cjs если еще у вас его не было. И там использовать ваш пакет.

module.exports = {
extends: ,
}

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

Заключение

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

Сегодня, стало более ли менее стандартом использование синтетических событий в современных js фреймворках, нежели обычный addEventListener. Но, как же работают эти события? В данной статье, я постараюсь на примере клика в Cample.js версии 3.2.0-beta.1 рассказать об этом.

Прежде всего, когда говорится о работе с событиями, очевидно, что речь заходит о конструкции addEventListener, которая выглядит следующим образом:

element.addEventListener(“событие”, “функция”, useCapture или options);

Но, так ли это быстро? Как оказалось, это не быстро из-за специфики работы.

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

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

Самая банальная идея событий на сайте – что-то выдаёт действие будь то мышка или клавиатура, а javascript вызывает функцию, которая на это событие срабатывает. Тогда, возникает необходимость в двух вещах – обрабатывать событие и где-то его хранить. Но, где?

Если отойти немного назад, то надо вспомнить о том, что DOM элемент является, можно сказать, объектом со своими свойствами. У него есть текст, у него есть следующий элемент и предыдущий и т.д. Так вот, что если функцию хранить в самом элементе (объекте) DOM? Это сразу решает две проблемы: как понять, “на что вызывать функцию?” и “где её хранить?”.

То-есть, грубо говоря, как это выглядит:

Соглашусь, что это выглядит странно, но, если получить элемент через getElementById, к примеру, и вывести его в консоль как объект, то действительно, это будет выглядеть как-то так, что мы присвоили свойство тегу в HTML (понятное дело, что элементу в DOM) со значением функции.

Так вот, остаётся вторая проблема, а как, собственно, обрабатывать событие клика зная, что у нас в DOM элементе есть функция. Это тоже достаточно интересный вопрос, но реализация очевидно будет связанна с addEventListener, потому что этот метод способен обрабатывать события.

Возникает тогда вопрос, а куда его ставить, если на Element в DOM будет медленно? Тут есть тоже достаточно крутое решение. Можно поставить обработку события прямо на документ, а в свойствах принимать target, по которому кликнули. Как это будет выглядеть в теории в javascript:

document.addEventListener(“click”, (e)=>…);

Таким образом, есть функция, которая срабатывает, когда кликается на элемент в document, а есть место, куда кликается. Так вот, это место клика как раз может являться объектом DOM, в который было вложено свойство с функцией срабатывания.

К примеру, в Cample.js, обработка будет выглядеть следующим образом:

const newEach = each(“new-each”,
()=>,
`

`
);

Для элемента div с id “el”, будет присвоена функция, которая приходит из импортированных данных. Если по документу будет кликнуто мышкой, тогда данная функция будет вызвана.

Примерно так, будет выглядеть синтетическая обработка события клик в современных фреймворках.

Всем большое спасибо за прочтение данной статьи!