Раз уж пишу про обновление документации effector, то расскажу, что сейчас сообщество активно пишет новые статьи и улучшает уже написанные!
Effector становится все более привлекательным инструментом для изучения.
Сейчас я не вкладываю много сил в документацию, так как недавно участвовал в программном комитете Podlodka React Crew #2, а также продолжаю дописывать контент для frontend.vision и активно стараюсь не выгореть.
Количество материалов по effector растет с каждым днём, я даже не успеваю вычитывать все новые статьи, поэтому активно использую некоторые AI-технологии для создания контента.
Например, я выкачал всю документацию и статьи, разбил на кусочки и посчитал эмбеддинги, чтобы в дальнейшем крайне быстро и точно искать по содержимому. Это супер сильно помогает при написании статей.
Вообще, это подход так называемого RAG (Retrieval-augmented generation), но вместо использования полноценного инструмента я собрал свой RAG дома на коленке используя NodeJS + SQLite запуская в CLI.
По сути, собираю уникальную пачку чанков из документации последовательным поиском, а дальше либо читаю глазами результат, либо компилирую в единый ответ через LLM.
Если интересно, расскажу как это работает подробнее
Effector становится все более привлекательным инструментом для изучения.
Сейчас я не вкладываю много сил в документацию, так как недавно участвовал в программном комитете Podlodka React Crew #2, а также продолжаю дописывать контент для frontend.vision и активно стараюсь не выгореть.
Количество материалов по effector растет с каждым днём, я даже не успеваю вычитывать все новые статьи, поэтому активно использую некоторые AI-технологии для создания контента.
Например, я выкачал всю документацию и статьи, разбил на кусочки и посчитал эмбеддинги, чтобы в дальнейшем крайне быстро и точно искать по содержимому. Это супер сильно помогает при написании статей.
Вообще, это подход так называемого RAG (Retrieval-augmented generation), но вместо использования полноценного инструмента я собрал свой RAG дома на коленке используя NodeJS + SQLite запуская в CLI.
По сути, собираю уникальную пачку чанков из документации последовательным поиском, а дальше либо читаю глазами результат, либо компилирую в единый ответ через LLM.
Если интересно, расскажу как это работает подробнее
Я каким-то образом пропустил Rust 1.85
Язык перешел на новую стабильную версию синтаксиса Edition 2024
https://blog.rust-lang.org/2025/02/20/Rust-1.85.0.html
Язык перешел на новую стабильную версию синтаксиса Edition 2024
https://blog.rust-lang.org/2025/02/20/Rust-1.85.0.html
Forwarded from Hacknote.js (Никита Балихин)
Системы эффектов
Недавно послушал выпуск Подлодки про "Системы эффектов в языках программирования" и решил поделиться некоторыми рандомными рассуждениями на эту тему.
"Окраска" функций
"Окраской" функций называется некоторая декларация эффектов, содержащихся в функции.
В JavaScript есть 2 варианта "окраски" функций:
-
-
Fun fact: эти 2 варианта можно скомбинировать, чтобы получить AsyncIterator, который можно перебирать оператором for await...of.
В языке Nim система эффектов позволяет окрашивать функции любыми эффектами, что выглядит весьма любопытно (на самом деле существует ещё множество языков с такой возможностью, но почему-то мне сразу вспомнился именно Nim).
Обработка исключений
В Java есть оператор throws, позволяющий "окрасить" функцию эффектом выброса определённого типа исключения и на этапе сборки удостовериться, что эти исключения обработаны.
JavaScript/TypeScript не позволяет типизировать исключения (разве что задокументировать их с помощью JSDoc или TSDoc), но теоретически эту проблему можно решить знаменитой монадой Either.
Чистота функций
Бандлеры используют аннотацию
В самом JavaScript нет языкового средства для выражения чистоты функции — то есть отсутствия в ней эффектов, хотя было бы классно использовать это знание, например, для исполнения кода во время сборки (как, например, c babel-plugin-macros).
Недавно послушал выпуск Подлодки про "Системы эффектов в языках программирования" и решил поделиться некоторыми рандомными рассуждениями на эту тему.
"Окраска" функций
"Окраской" функций называется некоторая декларация эффектов, содержащихся в функции.
В JavaScript есть 2 варианта "окраски" функций:
-
async
— обозначает, что функция асинхронная и позволяет использовать внутри неё оператор await
-
*
— обозначает, что функция является генератором и позволяет использовать внутри неё оператор yield
Fun fact: эти 2 варианта можно скомбинировать, чтобы получить AsyncIterator, который можно перебирать оператором for await...of.
В языке Nim система эффектов позволяет окрашивать функции любыми эффектами, что выглядит весьма любопытно (на самом деле существует ещё множество языков с такой возможностью, но почему-то мне сразу вспомнился именно Nim).
Обработка исключений
В Java есть оператор throws, позволяющий "окрасить" функцию эффектом выброса определённого типа исключения и на этапе сборки удостовериться, что эти исключения обработаны.
JavaScript/TypeScript не позволяет типизировать исключения (разве что задокументировать их с помощью JSDoc или TSDoc), но теоретически эту проблему можно решить знаменитой монадой Either.
Чистота функций
Бандлеры используют аннотацию
/*#__PURE__*/
, которая обозначает отсутствие побочных эффектов в функции, для более эффективного тришейкинга (упомянал об этом в своём докладе).В самом JavaScript нет языкового средства для выражения чистоты функции — то есть отсутствия в ней эффектов, хотя было бы классно использовать это знание, например, для исполнения кода во время сборки (как, например, c babel-plugin-macros).
Apple Podcasts
Podlodka #404 – Системы эффектов в языках программирования
Выпуск подкаста · Podlodka Podcast · 23.12.2024 · 2 ч. 3 мин.
В документацию effector.dev подъехал ПР
Теперь в навигации есть красивый переключатель разделов, спасибо @senzujuju
https://github.com/effector/effector/pull/1232
Теперь в навигации есть красивый переключатель разделов, спасибо @senzujuju
https://github.com/effector/effector/pull/1232
Знаете, когда 10 лет опыта в IT вложены не только в карьерный рост, но и в крутые сторонние медиапроекты и создание качественного контента? Вот Андрей Смирнов — это как раз такой случай.
Что он уже успел:
Уже 9 лет в IT-менеджменте — управлял людьми в X5 Tech, IPONWEB и Rambler.
Ведёт аж два подкаста: Frontend Weekend и «600k в секунду». Правда, второй уже давно пора переименовать в «1M в секунду» — инфляция, что поделать.
Организовал свою первую конференцию по софтовым навыкам Soft Weekend.
Регулярно выступает на крупнейших конференциях: TeamLead Conf, HolyJS, Frontend Conf, CodeFest и других.
Участвует в программных комитетах CTO Conf, Podlodka Teamlead Crew и ИТ-Пикника.
Но главное, почему я вообще об этом пишу — это его канал. Там не просто «сухая экспертность», а живые истории, личный опыт и много реально работающих советов.
Например, что мне зашло:
- «Как придумать идеальную тему для доклада»
- «Стоит ли доверять интуиции?»
- «Технические навыки у управленцев?»
Тексты Андрея реально приятно читать. Это не блогер, который через силу умничает, а думающий эксперт, делящийся своими размышлениями, опытом и самоиронией.
Рекомендую подписаться.
Что он уже успел:
Уже 9 лет в IT-менеджменте — управлял людьми в X5 Tech, IPONWEB и Rambler.
Ведёт аж два подкаста: Frontend Weekend и «600k в секунду». Правда, второй уже давно пора переименовать в «1M в секунду» — инфляция, что поделать.
Организовал свою первую конференцию по софтовым навыкам Soft Weekend.
Регулярно выступает на крупнейших конференциях: TeamLead Conf, HolyJS, Frontend Conf, CodeFest и других.
Участвует в программных комитетах CTO Conf, Podlodka Teamlead Crew и ИТ-Пикника.
Но главное, почему я вообще об этом пишу — это его канал. Там не просто «сухая экспертность», а живые истории, личный опыт и много реально работающих советов.
Например, что мне зашло:
- «Как придумать идеальную тему для доклада»
- «Стоит ли доверять интуиции?»
- «Технические навыки у управленцев?»
Тексты Андрея реально приятно читать. Это не блогер, который через силу умничает, а думающий эксперт, делящийся своими размышлениями, опытом и самоиронией.
Рекомендую подписаться.
Уже не первый раз вижу статьи раскрывающие проблему окрашивания функций в разные цвета.
Если коротко:
Мы не можем просто так вызывать асинхронные
Нам нужно "перекрасить" нашу синхронную функцию в асинхронную, добавив маркер
Энтони показывает как можно обобщить работу с синхронными и асинхронными функциями с помощью библиотеки
Правда это добавляет третий "цвет" функций — теперь нужно использовать генераторы, еще и в обертке quansync.
Но подход выглядит по крайней мере любопытно.
https://antfu.me/posts/async-sync-in-between
Если коротко:
async function red() {}
function blue() {}
Мы не можем просто так вызывать асинхронные
red
внутри обычных синхронной blue
функциий, а точнее дождаться результата.Нам нужно "перекрасить" нашу синхронную функцию в асинхронную, добавив маркер
async
, что повлияет на код использующий эту функцию, что в свою очередь потребует "перекрашивать" и этот код тоже, и так далее вверх по стеку вызовов.Энтони показывает как можно обобщить работу с синхронными и асинхронными функциями с помощью библиотеки
quansync
и генераторов.Правда это добавляет третий "цвет" функций — теперь нужно использовать генераторы, еще и в обертке quansync.
Но подход выглядит по крайней мере любопытно.
https://antfu.me/posts/async-sync-in-between
О, супер штука.
Я пока не потрогал, но концептуально мне очень нравится.
В мире opensource есть два основных подхода работы с пакетами:
А. npmjs-like
Б. go-like
Подход А — исходники пакета лежат где-то в git-репозитории (обычно github), через CI собираются и публикуются в сторонний реестр. Этот реестр гарантирует, что версия пакета не будет удалена, даже если с репозиторием что-то случилось.
Но это, вполне может вызвать расхождения между кодом в репозитории и кодом в реестре. В общем-то, ничего не мешает во время публикации, добавить любой код в бандл.
Частичное решение этой проблемы — NPM Package Provenance.
https://github.blog/security/supply-chain-security/introducing-npm-package-provenance/
Подход Б — работать без реестра, выкачивать код непосредственно из git-репозитория. Для гарантии сохраняются хеши версий, чтобы нельзя было подменить код в ветке или git-tag и таким образом внедрить уязвимость.
Но, в случае удаления репозитория, все зависимые проекты сломаются.
Новый тул, является дополнением к первому подходу npmjs-like. Он предлагает возможность проверить, собирается ли из исходников тот же код, что лежит в реестре.
Что может существенно повысить доверие к разработчикам.
https://blog.vlt.sh/blog/reproducibility
Я пока не потрогал, но концептуально мне очень нравится.
В мире opensource есть два основных подхода работы с пакетами:
А. npmjs-like
Б. go-like
Подход А — исходники пакета лежат где-то в git-репозитории (обычно github), через CI собираются и публикуются в сторонний реестр. Этот реестр гарантирует, что версия пакета не будет удалена, даже если с репозиторием что-то случилось.
Но это, вполне может вызвать расхождения между кодом в репозитории и кодом в реестре. В общем-то, ничего не мешает во время публикации, добавить любой код в бандл.
Частичное решение этой проблемы — NPM Package Provenance.
https://github.blog/security/supply-chain-security/introducing-npm-package-provenance/
Подход Б — работать без реестра, выкачивать код непосредственно из git-репозитория. Для гарантии сохраняются хеши версий, чтобы нельзя было подменить код в ветке или git-tag и таким образом внедрить уязвимость.
Но, в случае удаления репозитория, все зависимые проекты сломаются.
Новый тул, является дополнением к первому подходу npmjs-like. Он предлагает возможность проверить, собирается ли из исходников тот же код, что лежит в реестре.
Что может существенно повысить доверие к разработчикам.
https://blog.vlt.sh/blog/reproducibility
Вы наверняка слышали про Rspack — альтернатива Webpack, но на Rust и с совместимостью по плагинам и конфигам.
Приятно знать, что такие быстрые проекты развиваются и уже имеют весьма крутую экосистему.
19 марта релизнулся Rsdoctor.
По сути это аналог Statoscope, позволяющий дебажить и профилировать сборку. Особенно полезно в больших и сложных проектах, чтобы понять откуда и что заимпортировано.
Максимально актуально в связи с переездом экосистему на ESM, в ситуациях, когда два пакета имеют общую зависимость, но один пакет получил CJS версию, а другой ESM, в итоге в бандле две версии, странные плавающие баги и подобное.
https://rsdoctor.dev/blog/release/release-note-1_0
Приятно знать, что такие быстрые проекты развиваются и уже имеют весьма крутую экосистему.
19 марта релизнулся Rsdoctor.
По сути это аналог Statoscope, позволяющий дебажить и профилировать сборку. Особенно полезно в больших и сложных проектах, чтобы понять откуда и что заимпортировано.
Максимально актуально в связи с переездом экосистему на ESM, в ситуациях, когда два пакета имеют общую зависимость, но один пакет получил CJS версию, а другой ESM, в итоге в бандле две версии, странные плавающие баги и подобное.
https://rsdoctor.dev/blog/release/release-note-1_0
Из интересных проектов использующих Rspack экосистему — Lynx
Собирает React проект в Native приложения для мобилок.
Из любопытного: имеет кастомные директивы
https://lynxjs.org/react
Собирает React проект в Native приложения для мобилок.
Из любопытного: имеет кастомные директивы
"background only"
и "main thread"
для выполнения функций в разных потоках.https://lynxjs.org/react
lynxjs.org
Empower the web community and invite more to build cross-platform apps
Очень любопытный проект
Ходит на сайт с девтлузами React и строит граф зависимостей компонентов на странице.
К сожалению, исходники закрыты, проект на ранней экспериментальной фазе, но потыкать оказалось любопытно. Не требует установки.
https://react-explorer.com/
Ходит на сайт с девтлузами React и строит граф зависимостей компонентов на странице.
К сожалению, исходники закрыты, проект на ранней экспериментальной фазе, но потыкать оказалось любопытно. Не требует установки.
https://react-explorer.com/
В Next.js 15 убрали автоматическое кеширование
Перестать манкипатчить стандартные методы — движение в верном направлении.
Взамен появился
https://nextjs.org/docs/app/api-reference/directives/use-cache
А также
https://react.dev/reference/react/cache
А статья от Авроры показывает как использовать
Но использовать его можно только в компонентах, еще и без
Сомнительное решение, на мой взгляд, но в случае простых веб-страниц может действительно облегчить работу с отображением данных.
https://aurorascharff.no/posts/avoiding-server-component-waterfall-fetching-with-react-19-cache/
fetch()
.Перестать манкипатчить стандартные методы — движение в верном направлении.
Взамен появился
"use cache"
:https://nextjs.org/docs/app/api-reference/directives/use-cache
А также
cache()
в React 19:https://react.dev/reference/react/cache
А статья от Авроры показывает как использовать
cache()
для мемоизации вызовов экшенов
// When using cache(), the return value can be cached/memoized per render across multiple server components
const getComments = cache(async (postId: string) => {
return fetchedData // actual implementation here
});
Но использовать его можно только в компонентах, еще и без
await
:
export default async function PostPage({ params }: { params: Promise<{ postId: string }> }) {
const { postId } = await params;
// Prefetch the comments, but don't await the promise, so it doesn't block rendering
getComments(postId);
return (
<div>
<h1>Post: {postId}</h1>
<Suspense fallback={<div>Click Me Load More post...</div>}>
<Post postId={postId} />
</Suspense>
</div>
);
}
Сомнительное решение, на мой взгляд, но в случае простых веб-страниц может действительно облегчить работу с отображением данных.
https://aurorascharff.no/posts/avoiding-server-component-waterfall-fetching-with-react-19-cache/
Анализировать зависимости NPM-пакетов можно еще с помощью Node Modules Inspector
Умеет показывать не только граф зависимостей, но и ESM/CJS поддержку, использование транзитивных зависимостей, место на диске.
https://node-modules.dev/
Умеет показывать не только граф зависимостей, но и ESM/CJS поддержку, использование транзитивных зависимостей, место на диске.
https://node-modules.dev/
Насколько мне известно, появление поиска в ChatGPT, Google Grounding Answers, Claude Web Search сильно меняет рынок поисковиков.
Все больше пользователей ищут ответы на свои вопросы через AI, не утруждая себя подбором ключевых слов в Google.
Но насколько поиск через AI действительно лучше?
Автор проводит ревью существующих инструментов, рассуждает, как можно улучшить текущий поиск и какие у него есть проблемы.
https://paulstamatiou.com/browse-no-more
Все больше пользователей ищут ответы на свои вопросы через AI, не утруждая себя подбором ключевых слов в Google.
Но насколько поиск через AI действительно лучше?
Автор проводит ревью существующих инструментов, рассуждает, как можно улучшить текущий поиск и какие у него есть проблемы.
https://paulstamatiou.com/browse-no-more
Forwarded from amorgunov
Уязвимости в NextJS
Я думаю уже почти все слышали про уязвимость в NextJS, которая позволяет при запросах обходить миддлевары, и например, пропускать обработку авторизационных токенов и прочие серверные проверки. Уязвимость очень проста в эксплуатации, достаточно прокинуть http-заголовок
Наш проект это не затронуло, так как мы не смогли в свое время завести в нашей инфре стабильную работу миддлевар. Но пару месяцев назад мы столкнулись с другой уязвимостью на основе «cache poisoning», которая не получила столь бурную реакцию в интернете, но в нашем случае тоже могла бы привести к довольно критичным последствиям.
Cache poisoning (дословно, отравление кэша) - это атака, при которой обычным пользователям отображается вредоносный ответ на основе манипуляций с веб-сервером и кэшем.
Кэш позволяет отдавать идентичный ответ пользователю, который сделал аналогичный запрос. Как понять, что запрос аналогичный? У запросов должен быть одинаковый кэш-ключ, который обычно формируется на основе различных компонентов: тип запроса, хост, pathname, некоторые http-заголовки (конечно этих параметров может быть намного больше). Если ключ совпадает, то отдается сохраненный результат из кэша, если нет - то запрос начинает обрабатываться сервером.
Но есть компоненты, которые никак не влияют на ключ кэша (например какие-нибудь http-заголовки). И если какой-нибудь из этих компонентов может повлиять на ответ, то можно подложить отравленный результат в кэш, который будет возвращаться уже обычным пользователям.
Вот и мы нарвались на такую уязвимость в нексте (CVE-2024-46982). Если кратко, у NextJS в рамках page router-а есть режим SSR через функцию
Сам по себе
Более того, в этот JSON часто попадают значения http-заголовков, поэтому в него можно положить произвольный текст. А с учетом того, что запросы продолжают отдавать content-type равный text/html, то получаем еще и XSS абсолютно для всех пользователей, которые просто зайдут на страницу.
Подробнее про это можете почитать в блоге все того же профессора Рашида https://zhero-web-sec.github.io/research-and-things/nextjs-cache-and-chains-the-stale-elixir
Уязвимость уже была пофикшена в новых версиях NextJS, поэтому для фикса нам нужно было апнуть минорную версию, но это уже другая история.
Я думаю уже почти все слышали про уязвимость в NextJS, которая позволяет при запросах обходить миддлевары, и например, пропускать обработку авторизационных токенов и прочие серверные проверки. Уязвимость очень проста в эксплуатации, достаточно прокинуть http-заголовок
x-middleware-subrequest
, которая пропускает указанные миддлевары. Подробнее почитать можно в блоге Рашида Алама.Наш проект это не затронуло, так как мы не смогли в свое время завести в нашей инфре стабильную работу миддлевар. Но пару месяцев назад мы столкнулись с другой уязвимостью на основе «cache poisoning», которая не получила столь бурную реакцию в интернете, но в нашем случае тоже могла бы привести к довольно критичным последствиям.
Cache poisoning (дословно, отравление кэша) - это атака, при которой обычным пользователям отображается вредоносный ответ на основе манипуляций с веб-сервером и кэшем.
Кэш позволяет отдавать идентичный ответ пользователю, который сделал аналогичный запрос. Как понять, что запрос аналогичный? У запросов должен быть одинаковый кэш-ключ, который обычно формируется на основе различных компонентов: тип запроса, хост, pathname, некоторые http-заголовки (конечно этих параметров может быть намного больше). Если ключ совпадает, то отдается сохраненный результат из кэша, если нет - то запрос начинает обрабатываться сервером.
Но есть компоненты, которые никак не влияют на ключ кэша (например какие-нибудь http-заголовки). И если какой-нибудь из этих компонентов может повлиять на ответ, то можно подложить отравленный результат в кэш, который будет возвращаться уже обычным пользователям.
Вот и мы нарвались на такую уязвимость в нексте (CVE-2024-46982). Если кратко, у NextJS в рамках page router-а есть режим SSR через функцию
getServerSideProps
, которая подготавливает данные в формате JSON для страницы. Для этого некст при заходе на страницу отправляет запрос по пути /_next/data/...
. Но есть внутренний query-параметр ?__nextDataReq=1
, при добавлении которого к странице возвращается только JSON-данные для нее. И этот query-параметр не является частью ключа для кэша. Условно https://a.com
и https://a.com/?__nextDataReq=1
будут иметь один ключ. Если результат второго запроса сложить в кэш, то у всех пользователей вместо главной страницы будет открываться JSON с данными.Сам по себе
getServerSideProps
является динамическим и в кэш ничего не складывает. Но еще есть внутренний http-заголовок x-now-route-matches
, "включающий" SSG (server side generation) режим некста, который складывает результаты в кэш. Понимаете к чему я веду? Уязвимость заключается именно в этом и с помощью комбинации ?__nextDataReq=1
+ x-now-route-matches
и одного запроса можно сломать любую динамическую страницу приложения, путем складывания в кэш JSON-данных для страницы и отдачи их вместо html-контента.Более того, в этот JSON часто попадают значения http-заголовков, поэтому в него можно положить произвольный текст. А с учетом того, что запросы продолжают отдавать content-type равный text/html, то получаем еще и XSS абсолютно для всех пользователей, которые просто зайдут на страницу.
Подробнее про это можете почитать в блоге все того же профессора Рашида https://zhero-web-sec.github.io/research-and-things/nextjs-cache-and-chains-the-stale-elixir
Уязвимость уже была пофикшена в новых версиях NextJS, поэтому для фикса нам нужно было апнуть минорную версию, но это уже другая история.
Forwarded from BEARlogin Dev
Блокировки, блокировки, блокировочки...
Значит, бывает такая история, что сидишь ты понимаешь, на хорошем и дешевом хостинге и крутиш свои кубернейтесы. И все тебе збс и устраивает.
Но вот не задача, почему то (sarcasm) подсети этого хостинга начинают блочить провайдеры...
Смачно выругавшись начинаем искать варианты:
1. Переехать значит на православный хостинг и платить x100500 деняг
2. Купить на православном хостинге VPS, поставить там nginx в режиме stream и надеяться, что хостинг не заблокируют на уровне магистрали.
Для тех кто выбрал второй вариант, все просто.
1. Ставим nginx с поддержкой stream
2. Добавляем в nginx.conf
В отличие от стандартного http {} блока, stream работает на уровне TCP, а не HTTP.
Он не трогает заголовки, не читает Host, не парсит User-Agent
Он просто берёт входящий TLS-трафик и тупо прокидывает его дальше.
При этом это работает охуительно быстро, в отличии от обычного proxy_pass
Никакого overhead, никакой нагрузки на CPU, ничего не разбирается, не кешируется и не мутируется.
Это как туннель, только без OpenVPN и танцев с бубном.
BEARlogin dev — подпишись!
#блокировки #proxy #devops
Значит, бывает такая история, что сидишь ты понимаешь, на хорошем и дешевом хостинге и крутиш свои кубернейтесы. И все тебе збс и устраивает.
Но вот не задача, почему то
Смачно выругавшись начинаем искать варианты:
1. Переехать значит на православный хостинг и платить x100500 деняг
2. Купить на православном хостинге VPS, поставить там nginx в режиме stream и надеяться, что хостинг не заблокируют на уровне магистрали.
Для тех кто выбрал второй вариант, все просто.
1. Ставим nginx с поддержкой stream
2. Добавляем в nginx.conf
...
stream {
upstream k8s_https {
server ваш_ip:443;
}
server {
listen 443;
proxy_pass k8s_https;
}
}
...
В отличие от стандартного http {} блока, stream работает на уровне TCP, а не HTTP.
Он не трогает заголовки, не читает Host, не парсит User-Agent
Он просто берёт входящий TLS-трафик и тупо прокидывает его дальше.
При этом это работает охуительно быстро, в отличии от обычного proxy_pass
Никакого overhead, никакой нагрузки на CPU, ничего не разбирается, не кешируется и не мутируется.
Это как туннель, только без OpenVPN и танцев с бубном.
BEARlogin dev — подпишись!
#блокировки #proxy #devops