> 1. Насчет крона я думал, но все упирается в то, что задача у меня может выполняться несколько минут, тогда к моменту следующего запуска крона, она еще может быть не выполнена.
Еще раз, крон не нужен)) Берите supervisor.
> Я хотел сделать так без доп либ, на пхп
Я когда-то тоже городил подобный велосипед, сказать моуг следующее: смысла нет. Есть инструменты заточенные под очереди, лучше использовать их.
На счет обновленного кода:
Test не должен знать о таблице _tasks, у вас есть воркер, который занимается этим, закрывать задачу тоже он должен.
Со всей силы не понимаю, зачем вам `lock_next`? Если задача выполнена - добавьте finishedAt, или что-то вроде этого. Если вы делаете обработку задач по времени - то для этого используйте крон, а в задаче проверяйте что такой же инстанс существует, если существует - завершайте процесс.
Если же вы делаете очередь - то используйте сервер очередей.
Владимир Грабко
Я вам о кровищи из глаз, а вы мне про производительность)) Видите ли, код который пускай и очень быстрый но при этом сложный и непонятный - это угроза для проекта.
Dmitry Luchkin
> любой подход это череда компромисов.
Верно. Я набросил на laravel как раз потому, что многие компромиссы и принципы, заложенные в этом фреймворке противоречат критериям, что я описал выше.
Pavel Designer
Автор метит на QA на сколько я понял, а переделка ТЗ - вне ее должностных обязанностей. С чисто человеческой точки зрения желательно сказать об этом промахе в ТЗ.
> в laravel есть Form Request Validation
> Form requests are custom request classes that contain validation logic.
Верно, однако это не AR модели (а месседж был именно о них).
> используем phpDoc?
Можно, но это костыль. Я не спорю, бывают узкие кейсы, когда подобное необходимо, но свойства + их геттеры/сеттеры - это не тот случай.
Егор Неведов
> А насколько необходимы всё же виртуалки?
1 проект === 1 окружение === 1 виртуалка. У меня так практически все проекты (исключения бывают но редко). Пример: вам что-то потребовалось из проекта, в который вы не заглядывали год. Подняли окружение (5 мин), потыкали что надо, виртуалку можно уничтожать, проект с вагрантом останется. Без вагранта/докера - у вас это просто не выйдет.
Если вы работает в команде, единое окружение разработки - это святая святых. Сэкономите тьму времени.
> Если без них, и пока всего 1 проект, то какие минусы?
Да не вопрос, у вас допустим ubuntu, у вашего коллеги-фронтендщика - винда, а сервера под FreeBSD. Пакеты, на которые вы ориентируетесь под своей ОС, под фряхой могут в принципе отсутствовать. При выкатке своего детища вы с большой вероятностью можете обнаружить, что оно не работает.
Если же вы один на проекте и ваше ПО максимально близко к проду, ну что я рад за вас, но вы того, не забывайте, что менять свое окружение вам стоит синхронно с продом. Это такие себе кандалы. Если дома захотите поднять проект - не стоит забывать обо всех нюансах настройки, конкретно под этот проект.
> Ведь, я так понимаю, они удобны тем, что под каждый проект полностью своя среда, и гарантия ожидаемой работы за счёт этого, верно?
Да, верно.
Неявные зависимости. Плохо это тем, что ваш код гвоздями прибиваться к одной реализации внешнего сервиса. Как результат - с двумя реализациями вы работать не сможете.
Подобный код тяжело поддается тестированию потому, что зависимость нельзя заменить по интерфейсу.
Отлов ошибок осложняется за счет того, что у вас просто нет интерфейса объекта с которым вы работаете, просто кучка вызовов __callStatic.
Чем больше будете завязываться на магии - тем больше будете тратить время на ее разбор и дебаг, я уже молчу про тесты.
Глобальное состояние сервисов - это тоже самое, что и глобальные переменные, просто доступ к ним через статику. Почему глобальные переменные - это плохо я надеюсь объяснять не нужно.
-- --
Если вы подумали: "но это же удобно"! - Вероятнее всего вы просто не знаете с чем сравнивать. Удобство не определяется "меньше кода === лучше", удобство - это простота поддержки, тестирования и расширения.
Рекомендую почитать: Попросили проверить код, на что смотреть нужно?
Докер вставляет в процесс дополнительный уровень: связи между вашими контейнерами. Это помимо того, что ваше приложение должно знать о том, что где лежит. Контейнеры по своей идеологии должны быть иммутабельны, процесс разработки же требует постоянных изменений.
Егор Неведов Можете в сторону docker + docker-compose посмотреть. Vagrant правда для разработки удобнее.
То, что вам 4gb RAM хватает - чудо в 2016. Мне 16 бывает впритык))
Роман Денискин По ближе к вам)) Понимаете, то что вы привели по скилам - это стажер, даже не юниор.
Смотрите в сторону компаний, которые предлагают дальнейшую релокацию.
semki096
Нет 100% защиты, примите за исходную. Цель любой защиты - сделать ее взлом не выгодным, не более того. Именно по этому я и спросил, от кого вы пытаетесь защититься.
Посмотрел image.cms - багнутое днище. На странице установки даже в права на каталоги не смогли.
