Фёдор

должна

Должна кому?

Вес в 7мб это приемлемый вес или слишком много?

Желательно, чтобы сайт загружал контент видимой области до 2-3 секунд (lighthouse: mobile, 3-4g), остальное грузим следом.

В моем случае это сайт фотографа с множество png картинок

Перегнать в webp, ограничить стартовой загрузкой в 10 изображений и далее подгружать по мере скролла портфолио.

О, тут на самом деле есть куча факторов: как правильно уже сказали - есть оборудование провайдера со своими ограничениями. Есть ограничения у вышестоящего провайдера или провайдеров, сети и линий связи. Есть маркетинг провайдера: вам могут выдать тариф 1Гбит, но по факту это будет остаток от гигабитной лини, что приходит на весь ваш дом (у меня был такой случай - через пару месяцев "обещаний" обновить оборудование ушел обратно на старого провайдера, который не зажилил поставить второй коммутатор на дом только для меня одного). Так что гигабит в ДС и на дальнем востоке - это два разных гигабита. 30-40 мегабайт скорости в торрентах на гигабитном тарифе - очень даже неплохо на самом деле.

Есть ли какие-либо способы её обойти?

Один такой тут недавно память пытался разогнать :) Скорее всего, отскочит заменой матери (хотя память тоже могла погореть).
В ноутбуке, где каждый компонент работает на пределе тепловых возможностей - разгонять? Добить решили, чтобы не мучился?

Во первых аутентификацию. Авторизация это про проверку прав.
Если без REST API, то классика это принимать через POST запрос данные с формы.
Вот статья
Если кратко:
Делаете ручку /signin, которая проверяет пароль присланный пользователем с хешем паролей в базе данных (ну или где вы храните данные)
Если всё ок, создаете сессию, сохраняете сессию где нибудь в хранилище (опять же это может быть база данных, может быть ин мемори, есть библиотеки для этого, погуглите, да хоть в памяти приложения в мапе храните)
Далее ID сессии записываете в куки и посылаете ответ пользователю в заголовком Set-Cookie sessid="session_id", где session_id это айди который вы раньше сгенерили.
А далее пользователь ходит на ваш сайт, и какая нибудь мидлвара берет из запроса куки, берете оттуда id сессии, ищет этот айди в хранилище. Если нашла, то пропускает запрос дальше, если нет - 401 Unauthorized.
Ну в статье вобщем всё подробно описано.

Здесь отличное объяснение https://www.youtube.com/watch?v=WSMownyK7D8 ответ уже не для автора (ибо вопрос трехлетней давности), а для тех кто ищет ответ на подобное и натыкается на эту публикацию :)

Достаточно просто подумать "Чем я пользовался на этой неделе?", выбрать одно из существующих приложений и попытаться его повторить.

Попробуйте основательно разобраться, что такое полиморфизм, особенно одна из его разновидностей - полиморфизм типов.

Полиморфизм типов часто применяется в php. Вот его суть на вашем примере:

abstract class ClassName
{
    abstract public function doSomething($something);
//не абстрактные методы
}

class ChildClass extends ClassName
{
    public function doSomething($something)
    {
        //code
    }
}

class Main {
  public run(ClassName $class) {
    //code
  }
}

$obj = new Main();
$obj->run(new ChildClass());

Метод в Main::run() параметризован, его параметр $class теперь может соответствовать только дочерним классам вашего абстрактного класса ClassName.

Зачем это нужно?
Это нужно тогда, когда у вас может быть несколько реализаций одного и того же компонента. И вы точно знаете, что в будущем вам может понадобиться другая реализация. Например, представьте себе класс кеширования. Согласитесь, что кешировать можно в файл, можно в базу, можно в память и т.д. В таком случае, вы можете выделить абстракцию Cache с общим функционалом для любой реализации и создать наследников CacheFile, CacheMysql, CacheRedis и т.д.

Теперь когда вам понадобится компонент кеша, то вы можете внедрить его через параметр метода, который параметризирован типом Cache, если такому методу дать что-то другое, то интерпретатор кинет исключение. Вы же получаете гибкость. В любое время вы можете заменить реализацию компонента кеша на другой, просто передав в метод другой дочерний объект абстрактного класса Cache. Вы уже точно знаете, какой у него должен быть контракт и точно знаете, что вам не нужно вносить исправления в тот метод, который использует ваш класс Cache. Вы молодцы, ведь вы только что применили полиморфный принцип открытости/закрытости, одного из принципов SOLID а это значит, что ваш код стал чуть лучше.

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

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

Помимо примеров в гугле, смотрите еще и живой код open source проектов.
https://github.com/yiisoft/yii2/blob/master/framew...
https://github.com/yiisoft/yii2/blob/master/framew...
https://github.com/yiisoft/yii2/blob/master/framew...
и т.д.

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

А я за NULL! При ForeignKeys - корректное поведение, при unique - корректное поведение, при JOIN корректное поведение.
FK позволяют организовать целостность данных на уровне БД (CASCADE/RESTRICT/ SET NULL -это уже от бизнес логики) и там нет ON DELETE SET 123 или ON DELETE SET 0, что говорит само за себя, как и NULL значения при LEFT JOIN.
unique (column):
null
null
1
2
...
- и это нормальное и правильное поведение, т.е. значения уникальны, если они указаны. С 0 или суррогатным значением так не выйдет и будет расти еще один костыль.
По поводу экономии места - в нынешних реалиях, экономия на спичках.
Про обработку NULL / NOT NULL -если используется ORM либо обертка какая, то там это обычно реализовано прозрачно. К примеру Yii2: ArModel::findOne(['col' => null]) само развернет в нужный SQL код. В других фреймворках думаю тоже.
P.S. Имею ввиду MySQL, в других БД возможно по другому.

Учите базы данных, а именно сперва основы SQL, а после базы данных по типу MS SQL или MySQL.
Большая часть программирования, особенно в бизнес сфере связана с работами с базами данных, а какой язык и как выводит информацию - большинству не важно.

Что касается конкретно вашего вопрос, не понимая ООП и PHP в целом из вас получится низкоквалифицированный разработчик, который будет лишь собирать части пазл между собой, а не создавать свои и со сложными задачами без хороших базовых знаний вы не справитесь. Говорю вам как человек, который изначально так же "познакомился с фреймворками", а после понял, что без них не могу написать банальный функционал в виду отсутствия опыта и/или знаний. Так, что, учите ООП + свой язык и базы данных.

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

p.s. Когда-то даже в Nero burning rom такая опция была - нормализовать треки между собой при записи аудио сд =)

Задачи надо придумывать самому себе.
Иначе какой ты программист?

Какие курсы смотреть и проходить?

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

Откуда миф о нехватке кадров?

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

Начнём с последних - реклама курсов. Создаются курсы по IT с целью заработать деньги, а их реклама говорит, что ну НЕ ХВАТАЕТ айтишников, ну нет и всё! А зарплаты - сотка с порога.
Хотя почему их не хватает, кто это сказал, где статистика, графики, отчёты? Этих отчетов НИКТО и НИКОГДА не видел.
Касательно упомянутого автором веба: я начинал свой карьерный путь в начала 2003 года. Тогда уже были форумы по программированию, люди обсуждали, как заставить javascript работать в IE и NetscapeNavigator. Это было 20 лет назад почти. Как думаешь, за 20 лет сколько людей вкатилось в сферу программирования? Десятки тысяч стали полноценными специалистами.

Теперь относительно работодателей. У айтишников с незапамятных времен был такой фетиш - "да ты не знаешь бибилотеку Н? - Ну ты и лох" - образно говоря. Чем больше знал айтишник - тем он был круче, чем другие. Это был своего рода выпендрёж одних айтишников перед другими.
Но это было давно, опять же, лет 20 назад. За последние 20 лет индустрия рванула вперед настолько, что каждая технология, каждый ЯП оброс массой технологий-сателлитов. Для работы фронта нужно знание JS и каких-то там библиотек. Для работы с PHP требуют в вакансиях знания как минимум ТРЁХ фреймворков, не говоря о сопутствующих библиотеках, знания ОС unix/linux, DevOps, СУБД/высокие нагрузки, кэши-редисы, умение это все грамотно применять и т.д. Работодатели видят, что айтишник - это такой весьма покладистый тип личности, которого хлебом не корми, а дай что-нибудь поучить в свободное от работы время (ну а зачем зашуганному ботанику свободное время, пусть сидит дома фреймворки изучает). Вот работодатели и начали задирать планку и жаловаться, что "специалистов не хватает".
Да, сумасшедших гениев, кто знает целые вереницы технологий, намного меньше, чем обычных ребят, которые исполняют свою зону ответственности. А поскольку работодатели хотят сэкономить, то ищут этого фантомного чудо-программиста, который должен, по их мнению, работать за три отдела. Не находят и жалуются, что "специалистов не хватает".

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

Вклад в этот миф о нехватке спецов вносят сами разработчики. Сидел такой Петя, кодил 5 лет уткнувшись в монитор, потом его руководитель увольняется и, о чудо, Петя становится НАЧАЛЬНИКОМ отдела аж из пяти программистов. И вместо того, что бы делать свою работу хорошо, у Пети формируется синдром вахтера и Петя начинает задавать весьма заковыристые задачки на собеседовании, заставлять кандидата писать в режиме реального времени код, дает ему тестовое задание на 2 недели. А когда кандидаты сливаются, начальник-Петя, решает, он самый умный, а "спецов не хватает". Хотя проблема не в спецах, а в идиоте-Пете, который самоутверждается через свою должность главного формошлепа.

И что самое главное. Кому в РФ нужны айтишники? Бизнесу. В первую очередь.
Бизнесы развиваются в ногу со временем.
Взять в пример бизнесы 2010 года - что они делали? Свои веб-сайты, пилили какие-то свои наколенчатые решения.
Что делают бизнесы 2022 года? Идут на ВБ и Авито, покупают готовые продукты.
Время расставляет всё по местам, происходит оптимизация.
Что бы твою продукцию покупали больше не надо держать ИТ-штат для поддержки сайта, для этого есть ВБ.
А с учетом последних событий бизнесы будут неминуемо сокращать расходы.

Айтишники были в последние годы слишком дорогим удовольствием для бизнесов, айтишные аппетиты реально стали чем-то запредельно наглым, когда видишь, что Маша 25 лет с 2 годами опыта хочет 250 000 рублей.
Бизнесы в нынешних условиях неминуемо будут сокращать траты и условные Маши, которые вчера хотели 250 000 за JavaScript скоро будут работать за 50, тк таких Машек с каждым годом всё больше и больше.