Arman

у меня HP LaserJet Pro P1102 уже лет 7, пока была учеба - часто печатал, сейчас редко, может пару раз в месяц листов 100, за это время поменял барабаны и вал на картридже, пока работает нормально

картридж не чипованный, можно перезаправлять

Первые два вопроса не понятны.

2.1. Body не нужно указывать никаких padding'ов и margin'ов. Для header пропишите padding-top: 15px.
2.2. Сложно сказать.
2.3. Для footer пропишите padding-top: 15px.

P.S. Вообще сложно ответить на вопрос и что-то посоветовать не видя макет. Для разных случаев прописывается код по-разному.

Да, смысл есть, поскольку сейчас появились очень скоростные microSD и особенно SD (до 90 мБ/сек и более), которые при USB-2.0 просто не показывают, на что способны. Особенно рекомендую именно SD из-за того, что у них помимо скорости есть ещё одна очень полезная фишка - возможность залочить запись (microSD через адаптер тоже это позволяет). Это бывает полезно, если держишь на ней какой-нибудь ремонтно-восстановительный LiveUSB, который приходится втыкать в компы, зараженные всякой дрянью.
Сам я пользую вот такое устройство:

Его достоинства в том, что SD не торчит вбок, есть поворотная крышка и светодиодный индикатор обращения. На тех, что по вашей ссылке, индикатора скорее всего нет.
UPD: По этой теме нашлась полезная статья.

Даже если язык не меняет при формате "самописный сайт -> yii/laravel" то в любом случае разговор идет о том, что сайт создается заново. Наследуется только бизнес-логика. В остальных указанных случаях тем более все начинается с нуля.
Чаще всего переписывают только потому, что старое перестало удовлетворять требованиям. Например, был самописный сайт, который разрабатывался одним человеком. Затем бизнес-логика настолько разрослась, что заложенная изначальная архитектура плохо подходит для дальнейшей разработки или плохо масштабируется. Тогда начинают переписывать на php-фрейворках, чтобы можно было разрабатывать например команде разработчиков. Или вообще переписывают на другие языки программирования чтобы уйти от недостатков одного языка и использовать преимущества других языков/технологий.
Инициировать такой процесс может только руководство (правда чаще под влиянием разработчиков), так как в конечном счете платить придется именно руководству за новую разработку.
Профит в том, что создание нового позволит выбрать новейшие технологии, а значит получить максимальные дивиденды от их использования.
Подводных камней всегда куча и главным образом они связаны с тем, что при создании нового проекта, забываются некоторые нюансы, которые были созданы годы назад и уже хорошо протестированы. А при создании нового проекта о них просто можно забыть.
И как следствие, заказчик часто теряет поначалу, как раз потому, что "раньше работало, а теперь не работает". А все потому что забыли, не доделали, упустили из виду, и так далее. Но со временем чаще всего все понимают, что переписывание было не напрасным.

Нет
Да
Если мускул далеко

1) использовать composer
2) composer использует PSR
это типо что-то вроде этого:
vendor\Autoloader.php

<?php
/**
 * PSR-4 Autoload without composer 
 */
define('ROOT', __DIR__ . DIRECTORY_SEPARATOR);
define('SRC', str_replace("vendor\\","",ROOT) . DIRECTORY_SEPARATOR); // тут я удаляю из пути папку, в которой лежит данный автозагрузчик. В моём случае это папка "vendor"
 
spl_autoload_register(function ($class) {
    $file = str_replace('//', '/', str_replace('\\', '/', SRC .$class)) . '.php';
    if (file_exists($file)) {
        require_once $file;
    }
});

Структура проекта:

папка[root]->
        папка[vendor]->Autoloader.php
        папка[cars]->Car.php
        index.php

и далее делаете как хотите:
idnex.php

namespace kakoeto;

require_once 'vendor/Autoloader.php'; // тут подключается автолоадер
use Autoloader;

use cars\Car as Car; // вот тут подключаете всё что хотите. Главное, чтобы название класса совпадало с названием php файла, а-ля Car.php

.....
?>

Вот тут почитайте

Второй вариант по очевидным причинам - он тупо не работает по-умолчанию в PHP.

Первый же вкусовщина, можно использовать, никто не запрещает и минусов нет никаких.

Поучить что-то новое всегда имеет смысл!

Но вопрос в том, что учить. PHP - это лучший серверный язык для веба. Всякие высеры на этот счёт идут со времён PHP 4, сейчас он на 10 голов превосходит Ruby и Python. Он имеет нормальное ООП, инкапсуляцию, при этом исполняется быстрее. Так же, то что Вы уже упомянули, можно положить проект хоть на дешёвый хостинг, если нет нагрузки, то хранить куча сайтов за 5 евро. Уже давно не нужно стесняться PHP.

У Python есть свои плюсы, но явно не для веба.

На счёт ЗП, тоже все очень условно. О PHP стереотипы идут от засилия говнокодеров, хороший PHP-шник, который знает что такое ООП, DDD и другие важные вещи получает на уровне с другими программистами.

Если не для общего развития, а для профессии, я присоединяюсь к совету на счёт штудирования фронта. Vue.js или Angular. Быть full-stack полезнее, чем знать несколько серверных технологий.

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

Имея на вооружениее Laravel и Yii есть смысл в Ruby (Ruby and Rails)?

Нет

Работать будет. Дольше ли - неизвестно. Китайцы могут ставить любые дешевые аккумуляторы.

На webpack стоит переходить хотя бы ради адекватной инкрементальной пересборки в watch режиме и горячей перезагрузки работающей одинаково для всех браузеров.

Вместо babel лучше использовать typescript в режиме совместимости с js для старого кода (babel генерит совсем уж шайтан кашу и гораздо медленнее собирает).
Новый код сразу на typescript писать. (подсказки в ide на выводе типов и @types/* для библиотек здорово ускоряют процесс написания и частично компенсируют отсутствие тестов в проекте, если за них не платят - то есть всегда :( )

Даже если ориентируетесь исключительно на новые браузеры, всегда стоит использовать транспиляторы на этапе сборки (typescript умеет это делать без записи выходных файлов) чисто ради проверки корректности кода и соответствия типов (уже это поможет выкинуть половину тестов из обычного js, ибо не зачем проверять в рантайме то, что уже проверил транспилятор).

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

- babel следует подключать по возможности всегда, хотя бы для обработки es7-8 фишек, которые вам понравятся, но еще не успели внедрить во все браузеры.
- webpack можно подключить через gulp. Вполне можно выполнять отдельные такси с помощью gulp, а что-то обрабатывать с помощью webpack`а. Так же можно, например, запускать отдельные npm скрипты для выполнения параллельной или последовательной работы gulp и webpack. Особо полезные фишки webpack (имхо): tree shaking, [name][hash].ext корректное именование файлов на выходе, динамический импорт файлов.
- делать отдельные сборки для старых и вечнозеленых браузеров можно. Подключать можно используя

<script type="module" src="module.mjs"></script>
<script nomodule src="fallback.js"></script>

Подобный хак. Сначала подключаем сборку для браузеров, поддерживающих модули, и почти наверняка, весь es6 (e7-8 не обязательно, поэтому может потребоваться babel для транспилинга es7-8 в es6), а потом в качестве фаллбека подключаем файл в котором весь код преобразован в es5 (или ниже, если необходимо и возможно).

С 7 до 9 с наскоку не получится. Вначале до 8 потом до 9.

Но следует учитывать эту вырезку из Вики Debian:

Начиная со следующего выпуска Debian 9 (stretch), некоторые возможности будут исключены. Пользователям потребуется перейти на их альтернативы, чтобы избежать проблем при обновлении до 9.

То есть то что выпилили (особенно если вы это использовали) отвалится.

И обновиться можно только на ту же разрядность что у вас сейчас. Т.е. 32 на 32, 64 на 64.

CDN vs свой билд — экономия на спичках.
Тем более если вам не нужен весь пакет.

Начну с самого плохого, неправильного и убогого варианта использования:
Это когда люди подключают бутстрап.мин.цсс, а потом в своем файлике начинают переопределять стили. Получается полный неподдерживаемый пиздец (я как раз сейчас натягиваю на сайт купленный (!) такой шаблон, нервы на пределе).
Люди, которые так делают приводят гнилой аргумент: а вдруг мы захотим обновить бутстрап? Серьезно, блять? Как часто вы это делали? ставлю сто баксов, что ни разу.

Как делать по феншую.

Для начала, естественно, использовать препроцессорные исходники (не будем выбирать конкретный порт, есть и lеss, и sсss, и stylus, кому что нравится).

Далее миксины. Не нужно подключать отдельные. Подключите valiables.scss и mixins.scss. Миксины не попадают сами по себе в билд, так пусть они все будут доступны.

Компоненты. Отключите ненужные, закомментировав импорты соответствующих файлов.

Кнопки. Если бутстраповские не нужны, отключите их. Напишите свои, используя миксины и даже копипасту части кода из бутстрапа. Это нормально.
Отличный вариант, если вы напишете свой миксин для кнопки (который и бутстраповские миксины может использовать). Ибо в бутстрапе, к сожалению, нет миксина make-button().

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

Пагинация, крошки. Никогда вас не попросят поставить исходные стили. Если по макету эти элементы имеют определенный стиль, этот стиль будет сохраняться. Смело меняйте. Или делайте дубликат.

Хелперы использовать нужно как можно меньше. Они нужны для быстрых набросков или правок "здесь и сейчас". Лучше опишите новый класс.
Опять же если вам нужен класс list-inline в единственном месте, то почему бы его не прописать?

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

Чтоб слева-справа скроллить можно было, не боясь ткнуть на гиперссылку.

Из легко доступных и средних по цена/качество/емкость - это IKEA.
C9000 актуален и сегодня, но уже есть более современные версии. Тут больше играет финансовый вопрос

P.S. вспомнил про статью

db.collection.find(query).toArray.sort(customSortFunction)

При этом надо учесть, что это обычная сортировка средствами js, соответственно индексы не будут использоваться.

В конфиге приложения можно переопределить экшен для ошибок и в нем описать любую логику.

'errorHandler' => [
            'errorAction' => 'somecontroller/someaction',
        ],

www.yiiframework.com/doc-2.0/yii-web-errorhandler....
Только не совсем понятно что вы имеете в виду под "проверить в контент-страницах".