d-sem

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

Купил бы ты сам этот софт?

Если да, то не продавай, если нет, то продавай.
Да, тебя терзают сомнения, об упущенной выгоды, но по моему ты почти ничего не заработал за эти 10 лет на своем расширении. Да и исходники у тебя остаются. Сможешь запилить еще одно такое же))
Единственное что ты сейчас теряешь, как я думаю, статус чувака у которого есть софт с аудиторией 120 тысяч человек. Но за то получишь 8к. Хотя сможешь и сторговаться, получишь больше.

Куй железо пока горячо.

Учитывая, что тот же РНР прекрасно обрабатывает запросы вида ?foo[]=bar&foo[]=bar2, то уникальность явно не является обязательной.
А то что он видит как один (только не первый, а последний), то это как раз совершенно очевидно и банально.
Если вы в коде напишете
$array['foo'] = 'bar';
$array['foo'] = 'bar2';
То разумеется в $array останется только второй вариант, который тупо перезатрет первый. И Оппач тут совершенно не при чем.

Но вам никто не мешает написать свой парсер QUERY_STRING и брать из него неуникальные значения.

Обычно PHP в таком случае видит последнее значение. Используйте site.ru/?foo[]=bar&foo[]=bar2. Тогда в PHP будет массив $_GET['foo'] = ['bar', 'bar2'].

1) Хранить картинки в бд крайне кривое решение. Это может быть оправдано только в случае когда там хранится пара иконок, вставленная в текст прям через <имг срц="тут_бэйз64_строка"... и нет желания все это переделывать ради 2 кастомных микрокартинок. В остальном - конвертировать в картинку и хранить на диске. В бд писать путь до картинки. Если это какой-то аватар или картинка, связанная с другим объектом, соответственно заводить отдельную таблицу на картинки и связь один-к-одному или один-ко-многим, в зависимости от ситуации. В худшем случае поле в той же таблице, если точно будете знать что других картинок к объекту относиться не будет, но это должен быть путь до реальной картинки на диске.
2) Почему хранение в бд - плохая идея: При каждом запросе у вас будет вытаскиваться пару мегабайт данных из бд, передаваться по каналу соединения с бд, помещаться в память, и после этого еще нужно программно отдавать картину, кроме прочего картинка в бэйс64 занимает примерно на 30% больше места.
Когда у вас есть картинка на диске, вы просто вставляете путь до нее, это ~50 символов, и сервер отдает ее БЕЗ УЧАСТИЯ ПРОГРАММНОЙ ЧАСТИ, средствами вебсервера и ОС. Это быстрее, потребляет меньше памяти и занимает меньше места в хранилище.

import requests
s=requests.session()
s.headers={"X-Requested-With": "XMLHttpRequest"}
joke_text = s.post("https://randstuff.ru/joke/generate/").json()["joke"]["text"]
print(joke_text)

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

Ошибку 404

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

При наличии прямых рук:

1. Все полностью разбирается
   
2. Тщательно промывается дистиллированной водой в тазике и еще раз проливается потоком (продается в любом автосервисе бутылками, берите с запасом литров 10) - если где налет образовался, то можно аккуратно мягкой зубной щеткой потереть
   
3. Разъемы продуваются баллоном с воздухом
   
4. Оставляется сушится в теплом помещении на два-три дня
   
5. Еще раз разъемы продуваются баллоном с воздухом на всякий случай - могут капли остаться в труднодоступных местах
   

Далее собираем и смотрим - работает или нет. Если не работает - то надо уже смотреть что именно не работает и как именно. На промывку ноута у меня уходит примерно 4-5 литров воды.

1. Стоит ли продолжать изучение front-end, если данное направление реально нравится или ситуация действительно такая, что там уже не нужны новые люди?

Новых людей особо нигде не жалуют. Но пробиться всегда есть варианты:
1. Большие компании иногда могут нанимать стажеров по абсолютно любым направлениям и обучать их. Работа будет больше рутинная, но для старта можно и потерпеть.
2. Есть маленькие компании, у которых туго с деньгами, но разрабатывать им надо, соответственно нанимают того кто по карману. Развития здесь скорее всего не будет, но для первой строчки в резюме пойдет, если с 1 вариантом не получилось.

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

Попробовать конечно можно, за попытку никто Вам ничего плохого не сделает.
Но вообще джун-мидл-синьер - это вообще не про уровень знаний в программировании, это больше про софт скилы, которые приобретаются только с опытом работы. Условно я бы так разделил:
Джун - умеет писать код под достаточно конкретные задачи, умеет гуглить если что-то не знает, умеет спросить если не сумел загуглить.
Мидл - как джун + умеет декомпозировать более абстрактную задачу, при необходимости задать по ней правильные вопросы, умеет работать в команде (обсудить проблему, поревьювить чужой код, позаботиться чтоб собственный код был удобен остальным).
Синьер - как мидл + умеет решать проблемы бизнеса с помощью кода.

1. Делать простой бек для своих проектов на nodejs, чтобы проекты были более интересными и показывали мои навыки в js. Будет ли базовое знание nodejs плюсом для front-end разработчика?

Будет, большинство инструментария написано на node и конфигурируется js кодом. Ну и уметь накидать себе заглушку на express пока нормальное api в разработке тоже будет плюсом.

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

Не заморачиваться и делать все в одном github. Лучше заморочиться тем как этот github оформлен, например сделать readme для профиля. Нормально оформлять коммиты. Не плодить кучу форков разных чужих проектов. Если есть форк чужого проекта, обязательно должен быть пул реквест туда, ну или хотя бы собственные коммиты в форке.

3. Если я выберу nodejs и буду добавлять его к своим проектам, то нормально ли тогда будет подавать отклик и к фронт и к бек вакансиям?

Нормально. Как и нормально изредка менять направление, а значит и не знать что больше по душе пока не работал. Нормально будет, если полгода-год поработали с одной технологией, а потом несколько лет с другой, но плохо, если менее чем за 2 года смените 3+ стэка.
Я например начинал с php, через год ушел в node.js, еще через пару лет добавил фронт не убирая node.js, еще через 4 года добавил Rust.

найти работу во front-end нереально и джуны никому не нужны

Джужы и в остальных направления не особо не нужны.

1. Идете на собесы.
2. Записываете и затем устраняете те пробелы, которые не понравились интервьюеру.
3. Повторить первые 2 пункта.

1) speedtest единственное что не режут все провайдеры
2) торент трафик первое, что режут провайдеры при нехватке пропускной способности

Первый ответ от Яндекс говорит, что loadUrl переименован в loadURL.