Андрей Сергованцев

Попытаюсь ответить вам по пунктам, так как сам в своё время задавался теми же вопросами.

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

Для себя решил отказаться от Bootstrap, чтобы глаз нервно не дёргался, при взгляде на "винегрет" из разных именований. Компенсирую это разработкой библиотеки собственных компонентов, руководствуясь тем же Bootstrap и лучшими практиками.

2. Касательно использования em: рекомендую ознакомиться с этой статьёй
Пришло время попрощаться с единицей измерения px
Для блоков отдельно назначать font-size в px не нужно. Попробуйте правильно использовать rem, взяв за константу, что он должен быть по умолчанию 16px. Если нужно будет - отвечу подробнее.

Лично я использую em в медиа-выражениях и в случае крайней необходимости в блоках.

3. В случае чистого БЭМ - создайте блок с одним шрифтом и другим и используйте его как микс.

4. Если честно, стараться использовать готовые решения CMS можно, но я бы не рекомендовал. Когда работал с WP, всё время кастомизировал классы и вывод шаблона. На Битрикс с этим проще, можно даже собственный класс назначить для WISYWIG редактора.
Вопрос в том можете ли вы себе позволить такую кастомизацию или нет. Если это требует сверх ресурсов - оно того не стоит.

5. Я использую альтернативное именование, которое прижилось лучше всего в англоговорящих странах .block__element--modifier. На мой взгляд оно читаемее.

Вообще для расширения "БЭМ кругозора" рекомендую ознакомиться с этими статьями
More Transparent UI Code with Namespaces
Battling BEM CSS: 10 Common Problems And How To Av...

Я в своей работе на данный момент использую расширенный БЭМ, так называемый BEMIT (BEM + ITCSS). Для обычных сайтов - этого хватает с головой, в случае современного реактивного фронтенда требует обсуждения с командой и более глубоко понимания в проектировании АНБ (абсолютно независимый блок).

Надеюсь, что смог вам помочь, так как сам на решение этих вопрос вопросов потратил продолжительное время.

Незаконно, файлы d.ts это для библиотек, написанных на js, которым нужны тайпинги.
Если проект на typescript, то типы и интерфейсы следует импортировать явно.
Либо из models(interfaces, types, ...whatever), либо из сервисов, которые с этими типами работают.
Я склоняюсь к модульной структуре, т.е. интерфейсы лежат в отдельной папке, рядом с тем местом, где они применяются.

SVG + 2 маски, одна пропорционально растягивается, другая непропорционально. Отрицательным margin загнать секции одна на другую.

При почасовой оплате принято платить за то время, которое ты работал. Если ты 2 дня не работал, то тебе никто платить не обязан.

Бывают редкие исключения, если ты не работал по вине заказчика и потерял время, но такие вещи обсуждаются заранее и мало кто из заказчиков соглашается оплачивать потерянное время фрилансера.

В чем разница между поехать в отпуск и футболом?
И в том и в другом случае мы будем носить обувь.
Вот пример: в холодильник можно поставить пиво, а по карточке можно снять деньги в банкомате.

Ты, во-первых, не понимаешь что такое dependency injection, а во-вторых - что делает твой код.

Если отбросить все умные и красивые слова которые ты тут наскреб по сусекам, то оба твоих примера - про type hinting. Только в первом кусочеке кода мы просим интерпретатор проверять входящий параметр, а во втором - возвращаемое значение.
Type hinting двольно размытый термин, мне больше нравится "контроль типов", который используется в документации. Поскльку в данном случае это не "подсказка", а строгий контроль: скрипт упадёт с ошибкой если в первом примере в метод придет что-то отличное от класса реализующего интерфейс Foo, а во втором - если метод вернет что-то отличное от такого класса.

Контроль типов надо использовать, чтобы твой код был чище и работал предсказуемее.

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

плохо ищете )

Поиски литературы почему-то не увенчались успехом, пара унылых статей на хабре, море старой литературы старше 15 лет и курсы для новичков на udemy где описывается разница между insert и select.

все есть:

SQL Queries for Mere Mortals, 4th Edition
Год издания: 2018
Автор: Viescas J.
Жанр или тематика: Базы данных
Издательство: Addison-Wesley Professional
ISBN: 978-0134858333
Язык: Английский

Effective SQL: 61 Specific Ways to Write Better SQL
Год издания: 2017
Автор: Clothier B., Steele D., Viescas J.
Издательство: Addison-Wesley
ISBN: 978-0-13-457889-7
Язык: Английский

PostgreSQL Up and Running, 3rd Edition
Год издания: 2018
Автор: Obe R., Hsu L.
Издательство: O'Reilly Media
ISBN: 978-1-491-96341-8
Язык: Английский

PostgreSQL 9.6 High Performance
Год издания: 2017
Автор: Ahmed I., Smith G.
Издательство: Packt Publishing
ISBN: 9781784392970
Язык: Английский

PostgreSQL High Availability Cookbook
Год издания: 2017
Автор: Thomas S.M.
Издательство: Packt
ISBN: 978-1-78712-553-7
Язык: Английский

PostgreSQL 10 High Performance
Год издания: 2018
Автор: Ibrar Ahmed, Gregory Smith, Enrico Pirozzi
Издательство: Packt Publishing Ltd.
ISBN: 9781788474481
Язык: Английский

Database Systems: Design, Implementation and Management
Год издания: 2017
Автор: Coronel С., Morris S.
Издательство: Cengage Learning
ISBN: 978-1-305-62748-2
Язык: Английский

Designing Data-Intensive Applications / Высоконагруженные приложения. Программирование, масштабирование, поддержка.
Год издания: 2018
Автор: Martin Kleppmann / Клеппман Мартин
Издательство: Питер
ISBN: 978-5-4461-0512-0
Язык: Русский

Refactoring SQL Applications / Рефакторинг SQL-приложений
Год: 2009
Автор: Stephane Faroult / Стефан Фаро, Pascal L'Hermite / Паскаль Лерми
Издательство: Символ
ISBN: 978-5-93286-145-5, 978-0-596-51497-6
Язык: Русский

и даже ISO/IEC 9075:2011 буржуйский можно найти в pdf

index.php

<?php
# Author - Fedor Vlasenko, vlasenkofedor@gmail.com
define('METHOD', $_SERVER['REQUEST_METHOD']);
define('URI', parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH));

function router($url, ...$args)
{
    (empty($args[1]) || false !== strpos(METHOD, $args[0]))
    && (URI === $url || preg_match('#^' . $url . '$#iu', URI, $match))
    && die(call_user_func_array(end($args), $match ?? []));
}

router('/api/games', 'GET', function () {
    echo 'список игрушек';
});

router('/api/game/(\d+)', 'GET', function (...$args) {
    echo 'информация о игрушке: ', $args[1];
});

router('/api/games', 'POST', function () {
    echo 'добавить новую игрушку';
});

router('/api/games/(\d+)', 'PUT', function (...$args) {
    echo 'обновить существующую игрушку: ', $args[1];
});

router('/api/games/(\d+)', 'DELETE', function (...$args) {
    echo ' удалить игрушку: ', $args[1];
});

header($_SERVER['SERVER_PROTOCOL'] . ' 404 Not Found');
echo '404';

далее в консоли запускаем встроенный php сервер
php -S localhost:8000 index.php
тестируем и наслаждаемся :-)

Upwork же мне предлагает...

Upwork к вам лично обратился с таким предложением?)) Можно увидеть скрин?

Очевидно, что чем больше вы умеете, тем больше шансов взять проект. Часто заказчики хотят фулл-стек разработчиков. Ещё чаще хотят людей, которые уже знают технологии, которые используются в их проекте.

Но это не значит, что без знания всего этого нельзя работать. Чистые фронтендеры и чистые бекенды всё так же востребованы.
В любом случае для фронтендера очень приветствуется, если он способен полностью развернуть рабочую среду у себя на компе и хотя бы прочесть код бекенда.
Аналогично для любого бекендера считается нормой знать базовые принципы фронта.

А вот знание одновременно Laravel и ASP.NET - это бред. Потому что это разные бекендовые языки (С# и PHP) и их не принято мешать.

На изучение почти чего угодно в сфере ИТ обычно нужны эти 3 вещи:

1. время
   
2. терпение
   
3. английский
   

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

В процессе изучения, конечно, тебя сопровождает естественное любопытство. Но только лишь на нём не получится ехать всю дорогу. Когда начинается рутина или непреодолимые сложности, понадобятся воля и терпение. Да и всё то, что я перечислил выше.

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

какие паттерны применяются чаще всего на практике и где

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

1. Модули (делим код на независимые части)
   
2. Фабрики (для компонентов интерфейса)
   
3. Синглтоны (для хранилищ, точек сбора полифиллов / утилит и.т.д.)
   
4. Адаптеры (для зависимостей и полифилов, которые могут измениться / выпилиться)
   
5. Наблюдатели (для сбора происходящих событий в одном месте)
   
6. Хранители (для сохранения действий пользователя и "Ctrl-Z")
   
7. Стратегии (если действуем в зависимости от прилетевших данных)
   

Другим паттернам применение вижу редко, только если под какую-то замороченную бизнес-логику. Хотя кого я обманываю, на среднем сайте обычно происходит только один паттерн - доширак из костылей. Ну и стоит сказать, что SPA-фреймворки имеют свойство навязывать свои подходы к решению задач, но это отдельная тема.

Важно понимать, что паттерны проектирования - это просто хорошие идеи по поводу того, как организовать большой объем кода в той или иной ситуации. Это не "изучи тайное знание, запомни, и делай так всегда", не "используй паттерны, потому что великие их используют", это скорее "если не уверен как организовать код, возьми готовую идею, она вроде работает". Если вы будете просто решать задачи, то через N лет практики вы сами их все "изобретете", только не будете знать, что у них есть названия. Эффективно будет организовать себе заметку о том, какие из этих идей для чего примерно применяют, а потом, в процессе работы, в нее подглядывать, если встал вопрос "как организовать этот код".

Посмотрите в установленных плагинах (что не требуется отключите). Например , известны случаи, когда React-Templates - может все ломать .

При чём тут какая-то связка с php? Как php вообще относится к вёрстке? Если вы там адаптивности боитесь, то, лично моё мнение, вам ещё нужно подтянуть знания и вы себя в оценке переоценили))

Что насчёт самого макета, то я бы сказал, слишком лёгкий. Чё тут делать то? Карту вставить? Подвигать стрелочки при наведении через css? Сделать кнопку с раскрытием меню?

P.S. Я никак не хочу обидеть или оскорбить вас, но я не понимаю, сути вашего вопроса. У вас навыки 70% х 30%, а вы вместо того, что бы начать верстать, пришли сюда с глупым вопросом, а не слишком ли сложно!

Лечь поспать и с утра сделать все за 5мин. Не раз так уже справлялся с подобными проблемами когда кодю :)