smilingcheater

В примере ниже, метод makeInterviewer(): Interviewer возвращает тип интерфейса Interviewer.

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

Соответственно, никакой магии тут нет, просто в вашем примере не хватает классов-наследников с конкретной реализацией.

interface Interviewer {
    public function askQuestions();
}

abstract class HiringManager {
    abstract public function makeInterviewer(): Interviewer;

    public function takeInterview() {
        $interviewer = $this->makeInterviewer();
        $interviewer->askQuestions();
    }
}

class TeamLead implements Interviewer {
  public function askQuestions() {
    ...
  }
}

class Boss extends HiringManager {
  public function makeInterviewer(): Interviewer {
    return new TeamLead();
  }
}

https://www.php.net/manual/ru/language.oop5.abstra...

в начало crontab'а (sudo -u %username% crontab -e) добавьте строку
MAILTO=
с нужным мылом.

А вывод STDOUT команды занулите в /dev/null, чтобы успешные выполнения вам не прилетали.

MAILTO=email@example.com
0 */2 * * * /bin/backup.sh > /dev/null

PS: запускайте не через wget, а перепишите на php-cli и вынесите за пределы document_root сайта, чтобы из вне нельзя было до него достучаться.

1. Фрилансер - это черная дыра. Нет никаких гарантий, что вы с первого раза найдете хорошего специалиста. Вы потратите массу времени походив по рукам как портовая путана, потеряете массу времени и сил. В итоге скорее всего специалиста вы найдете, но какой ценой?

2. Нет слово бесплатно. Бесплатно будут работать только молодые специалисты, которых вы воспитаете. И то не долго, постепенно их интерес и отеческие симпатии пропадают, люди имеют свойство развиваться.

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

Вывод: Строить свою веб-студию можно только из своих коллег по цеху с которыми вы уже работали. Для этого желательно самому побыть фрилансером или же поработать в студии. Однако помимо кадровой работы у вас должна быть тонна знаний из разряда всего понемногу. Иначе вы останетесь без денег с лапшой на ушах

Можно в админере поправить типы полей или копируете это

и поочередно выполняете в sql консоле (/bitrix/admin/sql.php?lang=ru&del_query=Y).

*на случай если испортится содержимое полей сделайте полный бэкап всего сайта, плюс по возможности бэкап БД одним файлом без компрессии, плюс для верности mysqldump

Нет, нельзя получить idшник поста, еще до того, ка пост был создан.

В данном случае сама задача получения "полного адреса поста" абсолютно бессмысленная.
Мало того что ссылка может со временем поменяться - например вместо ламерского протокола http будет настроен нормальный https - но, главное, это сама по себе бессмысленная операция - сохранять те данные, которые уже есть в базе. То есть этот урл легко генерируется при получении данных из базы.

Непонятно только, почему в коде отсутствует сохранение ид юзера.

Вопрос даже не столько про GitHub, сколько про систему контроля версий. Что в нее должно попадать, а что - нет. По идее там должны быть все текстовые файлы, которые мы правим руками, и все, что нужно для сборки проекта. Чтобы можно было себе репозиторий склонировать, нажать кнопочку, и все недостающее собралось.

Если по типам файлов:

• Исходники с вашим кодом - однозначно да. Это самое главное.
  
• Все конфиги для сборки - да. Иначе без них проект не собрать. Исключение - какие-то ситуативно-локальные конфиги с ключами, паролями, и всем тем, что не должно попасть к другим людям. Но тогда это нужно описать в доках, что и где должно быть.
  
• Картинки - зависит от. SVG - скорее да, т.к. это текст. Растровые, особенно большие, может быть стоит хранить отдельно. Но это зависит от проекта и соглашений, главное избегать крайностей, чтобы репозиторий с лендингом не весил по пол гигабайта из-за исходников картинок или макетов. И это к любым бинарникам имеет отношение.
  
• node_modules - нет. Зависимости и зависимости зависимостей - это обычно тысячи файлов, которые вы никогда (ну почти никогда) не будете править своими руками. Они могут скачиваться при сборке проекта, в репозитории им делать нечего.
  
• Собранный и минифицированный проект - может быть. Зависит от применения. Обычно это не нужно хранить в системе контроля версий в том смысле, что минифицированные файлы мы все равно получаем при сборке и руками их не правим. Но иногда могут возникать ситуации вроде "хочу использовать репозиторий на GitHub как зеркало для моего NPM пакета" или "хочу захостить что-то на GitHub Pages", или "хочу, чтобы любая домохозяйка могла скопировать мой скрипт в свой бложик на wordpress и не парилась со сборкой", или еще что-то в этом духе. Иными словами, минифицированные файлы могут туда попасть, если вы понимаете, зачем это вам, какую задачу это решит. В общем случае пользы от этого никакой.
  

gsap это библиотека для анимации циферок. Не самая лучшая, не самая легкая, не самая бесплатная.

Лично меня заинтересовала https://animejs.com/

Что касается твоей задачи, не понятно в чем проблема? Тебе надо сверстать сначала все. Потом инициализируешь scrollmagic и добавляешь нужные блоки к сцене, указываешь когда и сколько их показывать. Если хочешь что-то делать с блоком, менять картинки например, то подписываешься на события от scrollmagic и делаешь что надо основываясь на значении прокрутки.

Как вариант:

const toggleOrder = () => {
  const params = new URLSearchParams(window.location.search);

  params.set('order', params.get('order') === 'DESC' ? 'ASC' : 'DESC');
  window.location.search = params.toString();
};

Пример. Код.

Фронт это всё, что видит пользователь. В том числе и вёрстка. В принципе не очень ясно, как можно адекватно заниматься фронтом, если не понимаешь, а с чем вообще имеешь дело. Куда вставляются данные, как они будут отображаться и так далее.

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