unst

Изучая ООП вам нужно будет понять:

1. основные принципы ООП: инкапсуляция, полиморфизм, наследование. И еще почитайте про абстракцию.
   
2. отличие self от static. Почитать про раннее и позднее статическое связывание
   
3. принципы SOLID
   
4. смысл инъекции зависимостей (Dependency Injection) и инверсии зависимостей (Dependency Inversion - один из принципов SOLID)
   
5. основные шаблоны проектирования (design patterns)
   

Ну и научитесь думать абстрактно) Не завязывайтесь на реализации, прорабатывайте интерфейсы.

Для GIF-ок есть Giphy и у них есть API
https://developers.giphy.com/docs/api/endpoint#search

с правильной лицензией
бесплатно
https://pixabay.com/api/docs/
https://www.pexels.com/api/
https://unsplash.com/developers
платно
https://developers.shutterstock.com/

с "ваще по всему" и "image reverse search" лучше парминга Гугла нету + поиск по картинкам дольше не показывается капча при автоматизаии

ну и то же самое, кроме reverse, dukduckgo

Серия статей на Хабре: "Сети для самых маленьких"

Хорошая книга для старта — Кормен, "Введение в алгоритмы". Можно и "Грокаем алгоритмы".

Стэнфордские курсы доступны на lagunita.stanford.edu.

algolist.ru

Именно по алгоритмам (а не по их анализу и дизайту) есть замечательный бесплатный курс с практическими заданиями на курсере. Вот первая часть. Отмечу, что проверка заданий проиходит по таким параметрам как стиль, корректность и эффективность. 6 недель каждая часть. К курсу есть книга.

Уменьшите битрейт и разрешение видео.
Переместите метаданные в начало mp4 контейнера
Установите preload="metadata"
htmlbook.ru/html/video/preload

Чтобы пиксели в глаза не бросались наложите на видео сеточку из маленьких черных точек
https://jsfiddle.net/soumyabg/wefLyrhp/
css background dotted overlay

У меня несколько ООО. Но свое ИП я открыл только недавно.
Я был шокирован тем, насколько это быстро и просто)))

Более того, сейчас уже не надо даже обращаться к сторонним компаниям, чтобы они помогли зарегистрировать юр. лицо. Это просто НЕ НУЖНО.

Итак, вот какой инструментарий я бы порекомендовал:

1. Регистрация ИП:
- https://service.nalog.ru/gosreg/
- www.e-kontur.ru/ip

Порядок действий

• Составляем форму самостоятельно (быстро, удобно, бесплатно)
  
• Формируем квитанцию для оплаты гос. пошлины (по-моему 500 руб.)
  
• Оплачиваем квитанцию
  
• Приходим в налоговую и просто подаем документы на регистрацию
  
• Через 5 рабочих дней забираем там же все документы
  
• Подаем заявление на переход на УСН (если нужно)
  

2. Открытие счёта в банке.
Я рекомендую банк Точка (человеческий сервис, удобный интернет-банк, все круто и недорого).
Здесь все очень просто. Оставляем заявку, присылаем сканы документов. Встречаемся с менеджером или по скайпу и все работает

3. Бухгалтерия
Сервис Эльба от Контура. 1 год для новых юр лиц - БЕСПЛАТНО. Удобно, внятно, бесплатно.

Тонкости
- Нужно подготовить документы? - Фреш Док
- Не забывать про то, что ИП должны платить взносы в ПФР и ФСС за себя

Будущее
Как только бизнес вырастет - лучше зарегистрировать ООО

Успехов!

"Алгоритмы на Java" Сэджвик, Уэйн
"Алгоритмы. Построение и анализ" Кормен
"Алгоритмы. Вводный курс" Кормен
"Алогритмы и структуры данных в Java" Лафоре

Много ответов есть уже, лучше попробую идти рядом с вашими словами. Итак,
> Зачем мне создавать файл, контролирующий это, если я и сам могу контролировать то, какие методы у меня есть
Вы - это ваша голова, вы человек, не робот, ваш может не быть на работе например, или вы сами можете забыть, как у вас взаимодействуют части системы. Интерфейсы - это в общем-то тоже документация. И не нужно строго различать "чисто интерфейсы", и интерфейсы класса - те методы, которые у класса паблик - это точно такой же интерфейс, только он явно не отделен от класса. Когда у класса всего 3-4 метода, и все они связаны простой идеей, то и выделять ничего не надо. Когда у класса уже 10 методов, и среди них есть небольшие смысловые группы, то уже имеет смысл эти группы подчеркнуть. И, в конце концов, вместо каши из 10 методов, вы читаете следующее: class Graph : IEnumerable, IIndexable, IDrawable - и вы знаете, что ваш граф перечисляется, индексируется и рисуется. Это уже очень много информации, вы уже понимаете, как взаимодействуют части вашей системы.

> Может создано это для работы в больших коллективах? Но ведь тогда любой участник сможет поправить и интерфейс.
Да, совершенно верно, для больших коллективов. Нет, участник просто так не сможет поправить интерфейс, не побеседовав с остальными. В лучшем случае участнику придется поправить весь код, который "висит" на этом интерфейсе, в худшем - он в принципе ничего не сможет поменять, если интерфейс "публичный" и используется несколькими командами разработчиков. Классический пример - системы плагинов. Если к MS Word-у уже написано куча плагинов, то MS не может взять и просто так поменять ифейсы, не поломав совместимость. Хотя некоторые аспекты реализации - может. Потому что, как уже сказали выше, интерфейс - это ДОГОВОР. Чем БОЛЕЕ он стабилен, тем ЛУЧШЕ. Команды договариваются (!), создавая интерфейсы, чтобы потом было как можно МЕНЬШЕ конфликтов и разногласий, т.к. проблемы с интерфейсом затрагивают всех. Найдите любую команду от 30 человек, и вы увидите, насколько это все важно.

Еще две вещи напоследок:
1) интерфейсы из ОО языков лишь частный пример понятие интерфейса в жизни вообще. Вы же, когда покупаете SATA-диск, наверное рассчитываете, что сможете его подключить к своему компу? А с чего вы взяли? А, ну конечно, ведь на упаковке написано SATA - значит производитель соблюдает ДОГОВОР - интерфейс передачи данных;
2) необходимость в некоторых фичах языков сложно осознать в личных проектах и даже в маленьких командах. Это тоже как в жизни: свой дом, как говорится, должен построить каждый мужик, а чтобы построить бизнес-центр или высотку, нужны определенные знания, т.к. другие масштабы. Это нормально. Тем не менее, нужно читать и искать примеры. Хотя современные ОО-языки и сами дают много примеров. Раз у вас PHP, почитайте про Iterator например.

Приведу пример на коленке. Хотим, например, написать абстрактную файловую систему. Для начала, определим интерфейс, для ФС:

interface FileSystemInterface {
  public function write($file, $data);
  public function read($file);
}

Затем, хочу реализацию интерфейса ФС для работы с файликами:

class OSFileSystem implements FileSystemInterface {
  public function write($file, $data) {
     // открываем файлик, пишем данные
  }

  public function read($file) {
    // открываем файлик, возвращаем данные
  }
}

Вдруг, кому-то захотелось файловую систему в облаке. Окей, не проблема, реализуем это:

class CloudFileSystem implements FileSystemInterface {
  public function write($file, $data) {
     // открываем соединение с облаком, пишем данные
  }

  public function read($file) {
    // открываем соединение с облаком, возвращаем данные
  }
}

Пусть у нас есть кой-то код, работающий с файловой системой, назовем его "Хранилище файлов". Пусть он выглядит примерно так:

class FileStorage {
  protected $Fs;
  
  public function __construct(FileSystemInterface $Fs) {
    $this->Fs = $Fs;
  }  

  public function saveFile() {
    $this->Fs->write('file.txt', 'file data');
  }

  public function getFile() {
    return $this->Fs->read('file.txt', 'file data');
  }
}

Отлично! Теперь мы можем хранилищу файлов отдать любой объект с реализованным интерфейсом FileSystemInterface. Пример:

// Хранилище файлов работает с файловой системой ОС:
$FS = new OSFileSystem();
$FileStorage = new FileStorage($Fs);
$FileStorage->getFile();

// Хранилище файлов работает с файловой системой в облаке:
$FS = new CloudFileSystem();
$FileStorage = new FileStorage($Fs);
$FileStorage->getFile();

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