John Bjornsen

Есть множество вариантов. На мой взгляд в качестве протокола наиболее удобно использовать ssh (sftp).

Вы не написали, в какой ОС вы работаете, но я просто упомяну, что чтобы не привязываться к IDE можно использовать, например, winscp(Windows) или lsyncd(linux) для live синхронизации кода.

В phpstorm, насколько я понимаю, наряду с ftp можно выбрать и sftp. Но нужно понимать, что переключении между ветками, когда код изменяется не через сохранение файла, а извне редактора он не будет синхронизирован с сервером. В таком случае для синхронизации всего кода удобно использовать rsync (что на linux, что на windows).

Насчет пользователя и прав - на мой взгляд, веб-сервер не должен иметь прав на запись к исходному коду. То есть нужно при создании инстанса на сервере создать структуру папок, где веб-сервер имеет права на запись только к runtime директориям. А синхронизируемый код - он должен быть доступен серверу только на чтение.
Отмечу, что я говорю именно об "девелоперском" инстансе, который нужен исключительно для текущей работы. Для инстансов, которые деплоятся автоматически из git ситуация с правами может быть иной и это отдельный вопрос.

> Знаю, что можно сделать деплой с помощью гита ...

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

Если есть вопросы - спрашивайте в комментариях, я дополню ответ.

Для начала почитайте что такое SAPI. Затем представьте что apache + mod_php разделили на web-сервер, который проксирует запросы на php-fpm и отдает статику, и собственно отдельный web-сервер который имплементит SAPI и выполняет запросы связанные только с php. То есть статику отдавать мы можем только через php. Суть примерно та же что и у apache2 + prefork + mod_php но оптимизированный только для работы с php. Так же можно поставить на фронт более быстрый и легковесный сервер который умеет проксировать запросы.

То есть php-fpm это эдакий fast-cgi сервер который постоянно держит готовые для работы пул-процессов (сколько в пуле процессов настраивается, так же как и от какого пользователя их запускать и все такое прочее). Каждый новый запрос уходит в какой-либо процесс из пула, запрос отрабатывает, возвращаем результат тому кто попросил (web-серверу обычно). Если процесс падает (fatal допустим) - поднимаем новый.

Принципиальной разницы между apache2+mod_php нету, просто упрощается инфраструктура. Наш web-сервер должен только уметь проксировать запросы и отдавать статику, а php-frpm вообще может быть на разных машинах (балансировщиком можно раскидывать запросы). Ну и сами понимаете, nginx + php-fpm будет быстрее обрабатывать запросы чем apache2+mod_php какой бы мы менеджер процессов не использовали в апаче. Минусов по сравнению с apache+mod_php я даже не могу предложить.

А php-runtime не зависит от этого. Он один на всех, CLI, FPM, mod_php...

Разве в mysql нет функционала периодического запуска кода по расписанию? Вроде Event Scheduler

Привет приятель. На Go можно написать все что угодно.
Но, тут нужно понимать что ты конкретно хочешь от проекта. Если это не масштабируемый интерпрайз проект лучше пиши его на php. Это я для отступления хоть и не совсем по теме.

А так лови полезные ресурсы:
https://github.com/golang/go/wiki/SuccessStories
https://github.com/golang/go/wiki/FromXToGo

https://www.youtube.com/watch?v=dLfGx_E131U
https://www.youtube.com/watch?v=KQcWXRlAiyA
https://www.youtube.com/watch?v=9u2zGBSkTCI&list=P...

Примеры:
https://github.com/pepelsbey
https://github.com/Samdark
https://github.com/mdo

Как заинтересовать работодателя:
1. Аватарка. Да, она должна быть. Ещё лучше, если это будет ваша фотография. Если видишь в профиле дефолтную аватарку, возникает ощущение, что GitHub у человека всего лишь для галочки.
2. Контактный email.
3. Полоска активности должна быть зеленой (см. примеры выше), но в меру — не нужно стремиться окрасить каждую клеточку, отдыхать тоже нужно. Если заходишь в профиль, а салатовые клеточки изредка были год назад или наоборот появились только две недели назад, то страница работодателя не заинтересует.
4. Ссылка на персональный сайт.
5. Наличие собственных public репозиториев. Работодатель хочет увидеть ваш код, поэтому очень желательно наличие в них свежих коммитов. Каким должен быть отличный репозиторий на GitHub — тема для отдельного вопроса, тут напишу кратко: README, понятная структура, тесты, звезды.
6. Наличие вклада в Open Source проекты. Мне доводилось встречать профили, в которых были выполнены все пункты выше, но тем не менее их владельцы были очень слабыми разработчиками. Наличие вклада в крупные проекты с открытым исходным кодом — это однозначно вин. Очень желательно, чтобы он у вас был.
7. Stars, Followers, Following. Всё это тоже было бы неплохо завести. Если у вас много фолловеров на GitHub, значит скорее всего вы из себя что-то представляете в мире Open Source, раз другим интересно следить за вами.

P.S.: Хороший профиль на github сам может выступать в роли резюме. Очень часто хедхантеры через него и выходят на тебя.

Есть несколько вариантов решения это проблемы.

1) Некоторые могут пропагандировать сервисный слой (design-pattern.ru/patterns/service-layer.html), как следствие: "App/Services/ServiceName" - набор классов, отвечающих за какое-то абстрактное действие. Например: "UserAvatarUploaderService", который отвечает за загрузку аватарки пользователя.

2) В качестве альтернативы и способ, который предпочитаю я - это создание директории "src" с набором независимых компонентов, включая собственный composer.json. Тот же сервис загрузки аватарки будет выглядеть следующим образом:

- src/
    - AvatarUploader/
        - README.md
        - composer.json
        - tests/ ...
        - src/
            - AvatarInterface.php
            - FileSystemInterface.php
            - FileSystemUploader.php
            - UploaderInterface.php

Для подключения этой библиотеки достаточно будет прописать в корневом:

{
    "repositories": [
        {
            "type": "path",
            "url": "./src/AvatarUploader"
        }
    ],
    "require": {
        "app/avatar-uploader": "*"
    }
}

А выглядеть внутренний (т.е. внутри "src/AvatarUploader") composer будет так:

{
    "name": "app/avatar-uploader",
    "autoload": {
        "psr-4": {
            "AvatarUploader\\": "src/"
        }
    }
}

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

Делаете ветку master, ветку dev и отдельные ветки под отдельные фичи.
Делаете 2 сайта - один сам проект (основной) - на него выкатываете master, второй сайт тестовый - на него выкатываете ветку dev. Остальные ветки разрабатываете, сливаете с dev выкатываете на тест, если там всё нормально то dev сливаете с мастером. За ноут просто когда садитесь если мастер новый есть делаете git pull и стягиваете новую версию

Я бы в корне создал папку lib или src и там уже по структуре namespace-ов папочки

На эту тему PSR-4 лучше почитать

А долго, это например сколько?
3-5 минут? Секунды? У каждого свое понятие долго.
Если хотите посмотреть по времени ответа сервера, возьмите сообщение, которое вам ВК в json формате посылает, и вставьте его например в Postman, и запросите через него адрес бота. Так вы сможете получить примерное время ответа вашего скрипта на сообщение. Ну а дальше, уже оптимизация. Естественно, если у вас хостинг, а не VPS то скорости будут совсем не ахти.

P.S. по два сообщения скорее всего из-за превышения времени ожидания или ошибки. Вы CallbackApi используете?