Михаил Лялин

На самом деле, это проблема конкретных сайтов - они всегда должны быть доступны по HTTP, пусть и с безусловным редиректом на HTTPS. Соответственно, достаточно просто указывать протокол http://.
Но если сильно хочется заморочиться, то можно на клиенте в фоне делать запрос на адрес сайта с https:// и если придёт какой-то ответ 2XX или 3XX, подставлять этот протокол.
Другого способа узнать, работает ли сайт по тому или иному протоколу, кроме как сделать туда запрос, не существует.

Используйте штатный logrotate.

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

Если вы просто заставляете browser показать картинку меньшего размера, в действие вступают методы быстрой интерполяции, которые использует browser. Любое уменьшение не в целое число раз (например, в два или три) вызывает ситуацию, когда, например, три пикселя превращаются в два (когда вы картинку шириной в 600 пикселей показываете шириной 400). Цвета смешиваются, границы размываются.
Предварительная генерация изображений для разных разрешений или использование векторных изображений решают эту проблему так или иначе. (Это не означает, что вы можете вставить растр в SVG и сказать, что теперь эта картинка - векторная.)

Можно через powershell
посмотреть индекс
Get-NetConnectionProfile
и изменить тип сети
Set-NetConnectionProfile -InterfaceIndex 2 -NetworkCategory Private

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

Как лучше - зависит от конкретного случая, но, когда я занимался вёрсткой это выглядело примерно так:
0. Используем препроцессор, какой-нибудь, например SASS (SCSS)
1. Благодаря препроцессору, среди прочего - Вы можете дробить файлы стилей на сколь угодное число оных (хотя, я бы так делать не стал)
2. CSS (при нашем подходе) мог делиться на следующие части:

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

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

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

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