Laravel по-русски

Слишком широкий вопрос. Начни со списка OWASP-10 и вообще почитай про этот проект хотя бы на Википедии.

Я как-то написал статью про такую "дыру" в одном существующем движке.

Отключение внешних ключей - плохая идея с точки зрения целостности базы.

Тут однозначного ответа/совета быть не может - у каждого свое понимание ООП (а кто-то вообще против него, хоть таких в PHP не много). Так что ниже сугубо мое личное мнение.

Ты столкнулся с ситуацией, когда излишняя иерархия вредит. Есть две иерархии: плоская (по сути, отстутствие иерархии) или полная (предельная группировка по пространствам имен, как в твоем желаемом примере с App\TelegramBot\Actions\Keyboards\Xyz...).

Когда-то, в PHP до версии 5.3 пространств имен (namespaces) не было. Во многих ЯП их нет до сих пор (Си, JavaScript, Lua и пр.). В этом случае проблема коллизий (совпадений имен, когда у тебя есть класс Foo и у библиотеки тоже есть класс Foo) решалась путем префиксов и суффиксов. Например:

MyTelegramBotKeyboardAction

Когда появились NS и народ кинулся в другую крайность, получилось так:

My\Telegram\Bot\Action\Keyboard

Интересно заметить, что первый вариант гораздо ближе к естественному написанию, чем второй ("my telegram bot's keyboard action" <=> "my telegram bot, (its) action (of/for) keyboard").

А еще интереснее, что многие вообще начинают совмещать оба подхода, и вот это мне совсем не понятно:

My\Telegram\Bot\Action\KeyboardAction

Ясно, что так проще (короче) писать use, но это уже совсем масло-масляное ("ActionKeyboardAction") - может тогда это промежуточное пространство имен вообще не нужно?

Я лично сторонник полу-плоской иерархии. NS отлично выполняют задачу изолирования твоего кода от окружающего, но зачем идти дальше и изолировать твой же код сам от себя? Ты ведь и так не допустишь коллизий по именам, код-то твой собственный. В этом случае имена могут выглядеть так:

MyTelegramBot\KeyboardAction

То есть одно большое NS, где внутри все остальное, без под-NS. Такая структура позволяет избежать use практически целиком. Например, если у тебя есть класс App\TelegramBot\Commands\SomeCommand и ему надо вызвать метод у Core, то ты будешь писать так:

class SomeCommand {
  function foo() {
    \App\TelegramBot\Core::bar();

Или так:

use App\TelegramBot\Core;

class SomeCommand {
  function foo() {
    Core::bar();

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

А вот если у тебя и Command, и Core в одном NS - то никаких проблем:

class SomeCommand {
  function foo() {
    Core::bar();

Получаешь лучшее из двух миров - use не надо (ибо классы в одном NS), в то же время ссылаешься на класс, как будто бы use был.

Таким образом, use или пути остаются только для зависимостей (библиотек), но это неизбежное зло и обычно к классам из библиотек обращений на порядок меньше, чем к собственным, так что озвученная проблема особо не стоит.

Я думаю, тебе стоит почитать про ООП в PHP подробнее, потому что у тебя путаница: use не вызывает автозагрузчик и вообще никак не относится к нему. Автозагрузчик сам по себе. Когда ты пишешь use, ты просто создаешь псевдоним для отдельно взятого класса в рамках этого файла: вместо \Some\Class::foo ты можешь написать один раз use Some\Class и далее везде просто Class::foo.

В доке по PHP все очень хорошо расписано:

• Автоматическая загрузка классов

• Использование пространств имен: импорт/создание псевдонима имени

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

Все это от характера конкретного проекта зависит, и от изобретательности заказчика тоже, конечно.

Например, учитывая, что народ по большей части разбегается в течении первых пары недель, можно поручать экспериментальные задачи - набросать интерактивный прототип дизайна, или какой-нибудь импортер из Excel'я (если это интернет-магазин). Таких мелких задач всегда можно набрать с десяток, а давать их уже проверенному человеку обычно как раз не хочется из-за того, что часть пойдет на выброс. В то же время именно эти задачи достаточно конфликтны и это хорошая проверка для людей (кто-то просто на дух не выносит кнопочки по экрану двигать, так что готов заказчику дать в физиономию, и лучше это выяснить сразу).

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

Или у тебя может наклевываться хороший заказ, который надо брать в работу вот прямо сейчас, а свободных знакомых нет. Потыркаешься неделю, две, заказчик посмотрит на это и пойдет дальше, особенно если у него уже сервер есть, каике-то доступы к API куплены и тому подобное. В итоге да, ты лишних денег не потратил, но и заказ ушел.

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

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

Я поэтому про allow_request и написал. auth.php может проверять файл на наличие, какую-то строку в БД и пр.

Позволять выполнять shell-команды из PHP - плохая идея с точки зрения безопасности.

Вообще, желательно, чтобы веб-сервер выдавал плашку "обслуживание", а не само приложение. С сервером нет шансов, что какие-то запросы "протекут" (потому что для них middleware не работает или еще что-нибудь подобное). В случае с nginx это делается добавлением набора allow/deny в блок server или location:

allow 1.2.3.4;
allow 5.6.7.8;
deny all;

Но есть и более интересный способ, про который мало знают. В nginx есть опция auth_request - с ней вопрос об аутентификации можно решать в контексте приложения! Когда приходит внешний запрос, nginx опрашивает этот URL и если в ответе код 401 или 403 - пользователю дается "отлуп" (который можно показать в виде красивой кастомной страницы об ошибке путем error_page). В отличии от ручного прописывания allow/deny, здесь не нужно править конфиг сервера, перезапускать его, вообще лезть в консоль, да и гибкость куда большая.

Выглядит это примерно так (подробности в документации):

server {
  ...

  error_page 403 /403.html;

  location / {
    auth_request /auth.php;
    include fastcgi.conf;
  }

  location = /auth.php {
    include fastcgi.conf;
  }
}

Это стандартное поведение, наверное, всех веб-серверов. Если по адресу есть директория, а URL не оканчивается на слэш - до PHP/Laravel такой запрос даже не доходит - редирект возвращает сам веб-сервер. А в чем проблема? Ты хочешь, чтобы по адресу .../blog отдавалась одна страница, а по адресу .../blob/ - другая?

Это плохая идея, будет путаница и, вероятно, с SEO тоже вызовет проблемы. Решение, если и есть, зависит от конкретного используемого веб-сервера (что еще одна причина не ломать стандартное поведение - сложно будет поддерживать).

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

Если запостил что-то личное - нажми "Пожаловаться", я удалю.

VIEW это механизм, встроенный в СУБД. Соответственно, он более безопасный и быстрый (в общем случае, т.к. MySQL не может оптимизировать сложные запросы к VIEW). Но из этого следует и то, что если хочется переносимости между разными СУБД - VIEW лучше не использовать. С простым WHERE куда больше шансов, что он заработает в PostgresSQL или в SQLite.

Вообще, в среднем проекте нет причин использовать VIEW. Обычно "проще" значит "лучше".

На PHP вполне нормально реализуются долгоживущие парсеры. У самого PHP утечек нет, у меня бывали и бывают процессы, которые стартуют с ОС и работают, пока не перезагрузишь. Это именно проблема (или "нецелевое использование" - как угодно) Laravel. В твоем случае достаточно переписать пару мест на "более голый" PHP (степень "голости" зависит от тебя). Python - это слишком радикальное решение, ИМХО.

В конце концов, "whereIn()->pluck()" это тот же PDO + array_column(), 2-3 строчки максимум.

А какой лимит по памяти у процесса (memory_limit)? Может ему и не нужно, т.к. памяти еще хватает.

Попробуй gc_collect_cycles(); - это вызовет GC принудительно.

Точнее сказать нельзя, потому что не известно, что там в getMissed().

Учти, что:

Так что статистика может быть нерепрезентативна. Сравни с memory_get_usage(false).

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

Скорость загрузки, действительно, не всегда зависит от разработчика. Может это интеграция с сервисом в далеком забугорье, может очень хитрый фильтр на миллионе записей. Без четкого описания среды ("фильтров 2, такого-то типа, записей не более 100, до БД пинг 1 мс") такие требования выглядят, как микроменеджмент.

Push'ы - тут еще интереснее, это из разряда "требовалось не менее 100 000 строк кода, мы добили разницу цитатами из Пушкина". Редко бывает задача, которую разбить на несколько коммитов ну никак нельзя. Иногда бывает, что целый день (а то и несколько) копаешь-копаешь в поисках непонятного бага, а кода - нет. Потом один коммит с исправлением на одной строчке, за которым десятки часов поисков. И за это вы будете штрафовать? Или будете требовать отчетов?

А "самописный" - это даже не технический термин, формально я написал вызов Eloquent - и это уже мой, "самописный", код, так что вовсе не ясно, что подразумевается под этим словом.

В общем, я посоветовал бы найти отличного спеца и оставить всю техническую часть на его совести, тем более вы, видимо, не видите разницы между push и commit, то есть у вас нет хорошего технического background'а, и если будете пытаться таким спецом рулить (всякие там "митапы" и "созвоны") - он или уйдет, или будет "сидеть на з/п", в итоге у вас в любом случае проект не выгодит.