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

Пока искал квартиру в Тбилиси была пара смешных историй. Первая — риэлтер, которая накричала на меня и "обозвала" претенциозным потому что якобы по вине приезжих цены так сильно взлетели, а теперь эти приезжие не хотят за эти деньги снимать. При этом она дважды сказала, что никто не хочет сдавать белорусам и чтобы я ехал обратно. Было смешновато. Вторая история похожая, нашлась одна квартира относительно недалеко от центра (в первую очередь относительно моей первой квартиры; если интересно, погуглите Ист Поинт в Тбилиси и оцените как далеко я жил) за $550. Новый дом, вменяемый ремонт, хозяйку всё устраивало. Когда я попросил реэлтера договориться о просмотре, хозяева внезапно передумали и сказали, что не хотят сдавать русским, белорусам и украинцам. На моё вполне резонное "А КОМУ, БЛЯТЬ, ОНИ ХОТЯТ ЕЁ СДАВАТЬ ЗА ТАКИЕ ДЕНЬГИ?!" риэлтер ответила "Я тоже поинтересовалась, они ответили, что американцам." Это была последняя капля.

Плюнул на всё, спросил у батумских знакомых как там принято искать квартиры, мне ответили, что пишешь в специализированные телеграм чятики и к тебе сами придут. Так и сделал. В итоге за приблизительно 15 минут нашёл двухкомнатную квартиру за $450 практически в центре Батуми. Для сравнения, то, что мне предлагали в Тбилиси — окраина города (аналог Каменной Горки в Минске, если знаете) за $650+. Было это ровно в день начала мобилизации в России, 21го сентября. Очень вовремя я, да.

Так в итоге я со всеми своими пожитками (чемодан, рюкзак, монитор и две коробки всякого барахла) погрузился в Toyota Camry (кстати, очень рекомендую в Грузии сервис по аренде авто с водителем gotrip) и за 6 часов и $100 комфортно добрался до точки бэ.

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

А тут кругом жилая застройка и моря не видно. Хотя нет, я вру. Видно, кнчн.

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

Будем посмотреть.

Stay tuned и Слава Украине!

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

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

Такие в общем и целом дела.

Stay tuned и Слава Украине!

Крч. Я сделал, чуваки.

Я сделал две абсолютно крутейшие штуки, которыми буду гордиться в ближайшие пару недель. Сегодня какой-то на удивление продуктивный день.

Я обожаю эту работу! Рок-н-ролл! 🤘

24 февраля 2022 года мир сломался. Во всяком случае для жителей Украины, России и Беларуси. Для кого-то в большей степени, для кого-то в меньшей, кто-то ещё не осознал до конца масштаб возможных последствий и пребывает в счастливом неведении. Но так или иначе зацепило или зацепит всех.

Где-то в начале апреля я разговаривал с поляком с моего проекта и пытался ему объяснить насколько это пиздец для любого вменяемого жителя Беларуси-Украины-России, рассказывал про мемориал "Три сестры" на границе этих трёх стран, насколько исторически мы всегда были связаны; да, часто воевали, конечно, но так или иначе наши истории очень тесно переплетены. Было бы странно это отрицать. И мой коллега, кажется, не очень мне поверил. В том смысле, что "если всё обстоит так, как ты говоришь, то как могло случиться, то, что случилось?!"

Я не знаю.

Я родился в 1983 году, вырос во времена, когда парады на День победы были многочисленными. Мы с одноклассниками ходили на эти парады и дарили ветеранам тюльпаны. Дядька моей матери в 16 лет пошёл на фронт, попал в концлагерь, бежал оттуда, добрался до Беларуси, попал в партизанский отряд, был ранен. Мы ездили к нему в гости поздравлять с Праздником. Он рассказывал нам об ужасах той войны. И День победы всегда был для меня праздником. А сегодня — нет. Сегодня 9 мая — повод для пропагандонов поугрожать миру ядерным оружием и проорать мантру "можемповторить".

Надеюсь, так будет не всегда и День победы снова будет Днём победы. Только уже над другими фашистами.

Сегодня я хочу только пожелать всего самого доброго украинцам. У вас всё получится.

Слава Україні!

В этом посте я попробую объяснить что такое virtualenv, для чего он нужен и как им пользоваться python-разработчику. Погнали.

🛫 Введение

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

Вопрос: Что такое virtualenv и почему мне обязательно нужно научиться им пользоваться?

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

Вопрос: Изолированное?

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

Вопрос: Как этим пользоваться?

Ответ: Условно работу с virtualenv можно разбить на несколько этапов, каждый из которых я постараюсь подробно описать в посте:

• Установка virtualenv
• Создание окружения
• Активация окружения
• <Здесь мы работаем как обычно, не обращая особого внимания на то, что мы находимся в каком-то там виртуальном окружении>
• Перенос окружения
• Деактивация окружения

Вопрос: Когда нужно использовать virtualenv?

Ответ: Я считаю, что всегда. Дело в том, что результатом разработки любой программы является её запуск на компьютере, который отличается от вашего. Это может быть какой-то сервер или машина другого пользователя. Использование virtualenv позовляет минимизировать опасность ставшей шуткой ситуации “Ну, не знаю, у меня на компе всё работает!”

🚀 Поехали!

Сейчас я расскажу подробно про каждый из этапов работы с virtualenv на примере. Уточню, что всё это я делаю только на Linux (Manjaro в моём случае), т.к. это моя основная рабочая система. Многое будет актуально и для Windows, но некоторые шаги будут отличаться, и придётся гуглить. Сорян.

1. Установка virtualenv

Не уверен на 200%, но кажется, что у меня virtualenv был установлен в Manjaro с самого начала. Если у вас не так, то установить его очень просто, используя менеджер пакетов pip:

# pip install virtualenv

Обратите внимание, что первым символом идёт “#”, а это значит, что команда должна быть выполнена под root’ом. Это важно. В противном случае вы увидите сообщение, а-ля ERROR: Could not install packages due to an EnvironmentError: [Errno 13] Permission denied: ‘/usr/lib/python3.8/site-packages/wcwidth-0.1.7.dist-info’. Нам это не нужно, поэтому либо смените пользователя через

$ su

и после этого выполните первую команду, либо сразу выполните её с sudo:

$ sudo pip install virtualenv

Символ $ в начале говорит о том, что команда выполняется из-под не привилегированного пользователя.

Вряд ли что-то пошло не так, и после установки вы можете проверить, что virtualenv установлен и посмотреть какая у вас версия:

$ virtualenv --version

У меня 16.7.9, но если у вас другая, вы вряд ли почувствуете разницу.

2. Создание окружения

Переходим к работе непосредственно с virtualenv. Например, вы начинаете проект my_project, который будет храниться у вас в домашней директории в директории Projects, т.е. /home/<your_username>/Projects/my_project. В моём случае это /home/dmrlx/Projects/my_project. Переходим в эту директорию:

$ cd /home/dmrlx/Projects/my_project

Теперь создаём в этой папке окружение. У меня в системе установлено два интерпретатора: 2.7.17 и 3.8.0. Например, установим virtualenv с Python 3.8:

$ virtualenv venv --python=python3.8

“venv” в данном случае — это название директории, в которой будет развёрнуто ваше виртуальное окружение, по сути его имя. Может быть любым другим, но, если честно, ни разу не встречал, чтобы кто-то писал что-то кроме venv. Возможно, разные имена имеют смысл, если у вас одновременно десяток проектов и нужно избежать путаницы.

Часть после “venv” вообще можно опустить. В этом случае виртуальное окружение установится с той версией, которая задана у вас в системе по умолчанию.

Если теперь мы посмотрим на содержимое директории “my_project” (в которой сейчас находимся), то увидим, что в ней действительно появилась директория “venv”, а внутри неё, в свою очередь, ещё три: “bin”, “include” и “lib”.

$ ls venv 

bin include lib

Круто! Пока всё идёт по плану.

3. Активация окружения

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

Выполним следующее:

$ source venv/bin/activate

Как только вы это сделаете, перед строкой приглашения вашей консоли появится “(venv)”, например у меня (было > стало):

“[dmrlx@vws my_project]$” > “(venv) [dmrlx@vws my_project]$”

Это значит, что контекст переключен и теперь мы используем виртуальное окружение! И это очень круто!

4. <Здесь мы работаем как обычно, не обращая особого внимания на то, что мы находимся в каком-то там виртуальном окружении>

Например, вам нужно установить некоторое количество пакетов, чтобы использовать в вашем фреймворке. Возьму что-нибудь из своих рабочих: paramiko, pycodestyle, pydocstyle, pylint, pytest, pytest-html, requests, SQLAlchemy. Устанавливаем (здесь “(venv) $” обращает внимание, что мы выполняем операцию с активированным виртуальным окружением):

(venv) $ pip install paramiko pycodestyle pydocstyle pylint pytest pytest-html requests SQLAlchemy

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

(venv) $ pip list

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

Теперь вы работаете, пишете код, устанавливаете в ваше виртуальное окружение ещё какие-то пакеты. Снова пишете. Снова устанавливаете…

5. Перенос окружения

И вот настаёт счастливый день, когда вы хотите поделиться своим кодом с миром. Для этого нам нужно не только дать возможность скачать код из, например, github или gitlab, но и развернуть ТОЧНО ТАКОЕ ЖЕ окружение, какое было на вашей системе. Вот тут-то мы и начинаем понимать всю прелесть virtualenv’a. У нас уже есть это окружение, и нужно перенести его с вашей системы на внешнюю.

Для начала делаем “слепок” списка пакетов с их версиями:

(venv) $ pip freeze > requirements.txt

где

pip freeze — команда, которая выводит список всех установленных пакетов с их версиями

> — символ перенаправления вывода

requirements.txt — имя файла, куда мы складываем список пакетов из pip freeze; можно назвать иначе, но так принято )

Файл “requirements.txt” можно и нужно хранить в корне вашего проекта (прямо в директории my_project) и отдавать его в продакшн вместе с кодом. Это хороший тон. А вот класть в репозиторий папку с вашим виртуальным окружением — моветон и “так уже не носят”. Чтобы избежать этого, можете использовать файл .gitignore.

Итак, вы скачали файл requirements.txt вместе с вашим репозиторием на новую машину, и теперь вам нужно развернуть точно такое же окружение, какое было у вас на рабочей системе. Для этого вы по очереди выполняете команды из этого мануала, чтобы создать виртуальное окружение:

$ sudo pip install virtualenv 
$ cd <путь_к_репозиторию> 
$ virtualenv venv --python=<ваша_версия_python> 
$ source venv/bin/activate

и теперь устанавливаете необходимые вам пакеты, используя requirements.txt:

$ pip install -r requirements.txt

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

6. Деактивация окружения

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

$ deactivate

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

🛬 Эпилог

Virtualenv очень простой, но одновременно мощный и важный инструмент в арсенале любого питониста. Это то, что принято называть “must have”, и начинать им пользоваться лучше с самого начала. Учиться, так сказатб, хорошему. Это позволит избежать множества проблем при работе в команде, при работе на нескольких машинах (например, у вас дома есть ноутбук и десктоп, и вы разрабатываете на обоих), а так же сделает вашу жизнь чуточку удобнее, а волосы шелковистее.

❓ Остались вопросы? Не стесняйтесь задавать их в комментариях. ;)

🙃 Привет. Я Саша, мне глубоко за 30, сейчас временно живу в Тбилиси. Последние сколько-то там лет работаю Software Test Automation Engineer, пописываю на питончике, имею некоторое количество интересов, которые мне быстро приедаются и я их забрасываю. В этом бложике пытаюсь собирать свои заметки о разных штуках, которыми сам пользуюсь, и которые, как мне кажется, могут быть интересны кому-то ещё.

✉️ Если вам вдруг по какой-то причине понадобилось связаться со мной, то можете использовать один из следующих способов:

• - telegram: @dmrlx
• - e-mail: demuraalex@gmail.com

Так же вы можете подписаться на меня в социальных сетях:

• 🐥 Twitter
• 📷 Instagam

Да, #2. Я люблю что-то менять в жизни и скрипя зубами превозмогать. Экспериментом #1 был переход (успешный) с Chrome на Safari на всех устройствах. Благо у меня сейчас остались только iPhone, iPad и рабочий MacBook.

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

Сразу немного предыстории. С 2001 года я провожу львиную долю своего времени за компьютером. В "прошлой жизни" я был инженером-конструктором, рисовал всякое там 3D и мышка всегда была лучшим другом и помощником. Так что переход вряд ли будет очень уж простым. Но нужно попробовать. Говорят, так тоже можно жить и это удобно. Тачпад в макбуке, кстати, просто топовейший, вам не врали.

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

Штош, попробуем.

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

Допустим, мы хотим чтобы наш тест (из предыдущего поста) проверял на чётность не просто текущий таймстемп, а таймстемп плюс некоторое целое число, которое мы будем передавать в качестве параметра в тест. Чтобы это сделать, мы должны определить параметр командной строки, в который будет передаваться число. Для этого у pytest’а есть специальный метод “pytest_addoption”, который позволяет это сделать. Приводим conftest.py из предыдущего поста к такому виду:

import time
import pytest

def pytest_addoption(parser):
    """PyTest method for adding custom parameters."""

    parser.addoption("--additional_value", 
                     action="store", 
                     default=0, 
                     type=int,
                     required=False,
                     help="Set additional value for timestamp")


@pytest.fixture(scope="session")
def additional_value(request):
    """Handler for --additional_value parameter."""

    return request.config.getoption("--additional_value")


@pytest.fixture(scope='class', autouse=True)
def suite_data():
    print("\n> Suite setup")
    yield
    print("> Suite teardown")

    
@pytest.fixture(scope='function')
def case_data():
    print("   > Case setup")
    yield time.time()
    print("\n   > Case teardown")

В функции pytest_addoption() мы объявляем необязательный (required=False) кастомный параметр типа integer (type=int) с дефолтным значением равным нулю (default=0), а функция additional_value() является, собственно, хэндлером значения. Каждый параметр, который вы добавите в pytest_addoption() должен иметь такой хэндлер, чтобы вы могли работать со значением параметра в своих тестах или других фикстурах.

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

import pytest


class TestSuite():

    def test_case_1(self, case_data, additional_value):
        timestamp = int(case_data)
        parameter = additional_value
        print(f"      > Received from fixture timestamp is: {timestamp}")
        print(f"      > Received from command line parameter is: {parameter}")
        timestamp += parameter
        assert(timestamp % 2 == 0)

Собственно, всё. Запускаем:

Мы видим, что timestamp у нас нечётный (1630838805), но благодаря переданному значению (9) в сумме он стал чётным и тест PASSED.

Это очень синтетический пример, но, как мне кажется, достаточно понятный.

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

Я уже как-то пытался сделать небольшой цикл про PyTest на другой платформе, но застрял, кажется, на втором. Попробуем ещё разок.

В проекте, на котором я сейчас работаю как Software Test AutomationEngineer в качестве основы для тестового фреймворка используется PyTest. Фреймворк отличный и очень мощный, но, на первый взгляд, может показаться достаточно сложным, и, с, опять же, на первый взгляд, отвратительной, совершенно непонятной документацией.

Сначала расскажу в двух словах о структуре PyTest-проекта. Можно считать, что минимально он состоит из файла conftest.py, в котором по умолчанию хранятся т.н. "фикстуры" и, собственно, файла с тестами, например test_intro.py. Файлы __init__.py пустые и нужны в основном чтобы “поддерживать” структуру фреймворка.

pytest_intro
├── __init__.py
└── tests
    ├── __init__.py
    ├── conftest.py
    └── test_intro.py

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

Итак, рассмотрим наш conftest.py

import time
import pytest


@pytest.fixture(scope='class', autouse=True)
def suite_data():
    print("\n> Suite setup")
    yield
    print("> Suite teardown")


@pytest.fixture(scope='function')
def case_data():
    print("   > Case setup")
    yield time.time()
    print("\n   > Case teardown")

Здесь мы видим две функции (suite_data() и case_data()), которые и являются фикстурами. Об этом нам говорит декоратор @pytest.fixture. У этого декоратора есть довольно много параметров, но главным является scope. Scope говорит об "уровне", на котором будет выполнена фикстура. Всего их 4:

• "session" — означает, что данная фикстура будет выполняться для всей тестовой сессии;
• "module" — означает, что данная фикстура будет выполняться для каждого тестового модуля (читай "файла с тестами"), который мы будем запускать;
• "class" — означает, что данная фикстура будет выполняться для каждого сьюта (читай "класса"), который мы будем запускать;
• "function" — означает, что данная фикстура будет выполняться для каждого конкретного теста. Это значение является значением по умолчанию и его можно не указывать.

В нашем примере, фикстура “suite_data()” будет выполнена для каждого тест сьюта. Внутри сьютов содержатся тест кейсы, для которых будет выполнена фикстура “case_data()” если она указана как входной параметр для кейса.

Из фикстуры можно передать значение в сьют или кейс с помощью оператора yield. При этом после yield можно добавить ещё код, который будет выполнен после кейса. Таким образом можно сказать, что всё, что идёт до оператора yield является “setup” частью (подготовительной), а всё, что после — “teardown” (пост-часть). yield, к слову, может ничего и не возвращать (к в suite_data()), а просто быть разделителем, отделяющим сетап от тирдауна и это потрясающе удобно на практике.

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

Ну и напоследок напишем кейс, который будет забирать таймстемп из фикстуры case_data, печатать его и проверять чётность числа. Если число чётное результат будет PASSED, если нет — FAILED. Отступы с символами “>” добавлены специально чтобы было лучше видно как “иерархически” выполняются фикстуры.

Ниже приведено содержимое файла test_intro.py

import pytest


class TestSuite():

    def test_case_1(self, case_data):
        timestamp = int(case_data)
        print(f"      > Received from fixture timestamp is: {timestamp}")
        assert(timestamp % 2 == 0)

В тесте мы сначала приводим к целочисленному значению то, что нам возвращает фикстура case_data и присваиваем это значение переменной timestamp, затем печатаем строку, которая содержит этот timestamp для наглядности и в конце проверяем является ли timestamp чётным числом.

Запускается это всё из консоли командой

pytest -v -s tests/testfile_name.py 

где -v — “verbose” режим, а -s — перенаправляет аутпут в консоль.

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

pytest -vs tests/testfile_name.py::TestSuiteName::test_case_name

В аутпуте хорошо видно в какой очерёдности выводятся строки из suite_data(), case_data() и нашего теста. Получается, что фикстуры как матрёшки "оборачивают" тест и друг друга. Сначала фикстура со скоупом function "оборачивает" тест кейс, потом фикстура со скоупом class "оборачивает" тест сьют и так далее до session.

На этом, кажется, всё. В следующем посте я постараюсь рассказать про передачу параметров командной строки в pytest.

Stay tuned, так сказать

Привык я, крч, настолько, что даже купил себе подписку YouTube Premium потому что реклама на YouTube ужасна. Но эти вот видеоблогеры придумали искать спонсоров. И это пиздец! Я плачу за то, чтобы не видеть рекламы, а они беззастенчиво суют её в видосы да ещё и не размечают. И вот посреди нормального видоса я вдруг слышу "а чтобы отдохнуть от учёбы или работы вы можете купить себе PS5 с инновационными джойстиками и поиграть в ультрасовременные игры". Да вашу ж мать!!!

Но мир не без добрых людей.

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

Нет, меня не мучает совесть. Я плачу чтобы не видеть рекламы и сплю очень хорошо. Спасибо.

Ссылка на github страницу расширения, где вы сможете найти расширение для вашего браузера.