Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Точно понимаете?3млн руб и от полугода до года работы.
Чётко 3 млн, но сроки плавают вдвое?
Добрый день. Если не студенты, то уже можно не кокетничать и этот ценник назвать? Портфолио?
Закрыто, спасибо
Расценки у вас какие?
Портфолио засекречено?
Приемлимые цены засекречены?
Есть старый проект, его нужно переписать на Laravel с нуля. Основная работа на пару месяцев. Затем, скорее всего, доработки. Потенциально есть ещё несколько проектов.
Бэкенд на Laravel 7, PHP 7.4, phpunit (юнит-тесты - центральная вещь в разработке), MySQL и всём остальном, что понадобится.
Фронтенд полностью отделён, общается с бэком через API, о нём думать не надо.
Команда - архитектор и ему нужен помощник.
Никаких высоких нагрузок не предполагается, но есть нюансы с безопасностью.
Удалённая работа, полная занятость, от 75К / мес.
Попробуйте с этим что-нибудь сделать: https://github.com/laravel/framework/bl … s.php#L468
Проект - b2b зарубежный.
Из разработчиков - я + фронтендер, нужен помощник.
На бэкенде Laravel, на фронте vue.js.
В JS и Vue разбираться желательно, но не обязательно.
Занятость, как минимум, на несколько ближайших месяцев.
Можно удалённо, но нужно периодически встречаться в офисе (СПб)
В районе 50К в месяц или по часам.
Пишу юнит-тесты, использую SQLite-in-memory и RefreshDatabase-трейт.
Перед началом теста на пустую базу накатываются миграции.
Я записываю какие-то данные в модели и хочу проверить, что при следующей загрузке страницы они будут извлечены, как надо.
$this->refreshApplication();
Создался новый app, все сервисы пересоздались по новой, всё чистое.
Но теперь при запросах пишет, что нужных таблиц нет.
То есть, новый app, видимо потерял связь с нужной базой и у него она чистая.
$this->refreshDatabase();
Так по новой накатываются миграции, таблицы есть, но данных, которые я туда записывал уже нет.
Как решить?
Что хотите за это?
1. На основе чего нужно трезво судить о производительности?
2. Почему вы считаете, что здесь что-то нужно лечить?
3. Почему в моём Laravel изначально было 0 строк кода на JS?
Значит это не тот валидатор, а \Validator.
AlexeyMezenin, ясно, спасибо.
Для юнит-тестов, правда, придётся ещё и кастомный роутер как-то прокидывать, но это, кажется, тоже решаемо.
Siriuss, ну вот в чём разница, мы в этой теме и пытались выяснить.
Кстати, заметил, что если положить сайт в папку и указать в "app.url" что-то типа "http://example.com/subfolder/", то на asset() это никак не влияет, он пляшет от серверных переменных и всё равно рисует путь "http://example.com/assets/...", а не "http://example.com/subfolder/assets..."
htclog81, AlexeyMezenin, спасибо за ответы!
Но, например, я не могу всю форму закрыть.
Пользователь может заполнить форму на странице "/items/edit/25".
Но не может на странице "/items/edit/26", потому что 26 это не его объект.
То есть, надо загрузить объект с ID 25 и проверить, что его, скажем, `user_id` ссылается на текущего пользователя.
Но как в authorized() по правильному получить ID объекта?
Использовать текщуий роут как-то не совсем правильно.
Ведь, это класс, который проверяет какой-то абстрактный запрос, а мы его связываем с текущим роутом.
Вряд ли браузер кэширует в первую очередь vue-файлы, так как vue-файлы до него доходить не должны.
А какая ОС?
На линуксе, мне лично, оказалось намного проще всё нужное поставить без всякой Homestead.
Это реально вызывает такой затык?
Здравствуйте.
Вот пользователь редактирует какой-то свой объект. Заполняет форму и отправляет.
А я пишу валидатор для реквеста на основе FormRequest и прямо так указываю в экшене:
public function editSomeObject(SomeEditRequest $request, int $id)
{
}
В нём проверяется сама структура данных: все ли нужные поля заполнены, в требуемом ли формате.
Но, кроме того, ещё нужно проверить, существует ли вообще объект с таким ID, имеет ли авторизованный пользователь право что-то с ним делать, позволяет ли его статус менять указанные поля.
Где это лучше проверять? Как-то пытаться добавить в SomeEditRequest? Или оставить ему только чистую незамутнённую логику по простой проверки набора полей, а всё остальное уже проверять в контроллере/сервисе?
Сделать свой метод никогда не поздно.
Но, раз уж используется фреймворк, хочется писать в единообразном стиле, используя предоставляемые им средства.
Не, ну здесь мы каждый раз вручную собираем путь из разных переменных, как в старые добрые времена вордпресса.
asset() никак тут не помогает, только root впереди подставляет.
Можно и так написать:
src="{{ asset('') }}{{ env('THEME') }}/images/articles/"
и так:
src="{{ asset(env('THEME').'/images/articles/') }}"
Или в THEME ещё и забить домен и вообще без asset() тоже самое получить.
Профит был бы, если писать просто asset('images/articles'), а он уже сам смотрит в env('THEME').
P.S. А это идеологически правильно напрямую env() дёргать, в обход конфига?
Ну, это и была моя первая мысль, озвученная в самом начале.
Что я указываю путь внутри некой абстрактной папки assets, а потом в каком-нибудь конфиге могу менять путь к ней прозрачно для шаблонов.
Но, вот, где это настраивать можно, я не нашёл.
Можете объяснить сакральный смысл следующего?
class AppServiceProvider extends ServiceProvider
{
/**
* Bootstrap any application services.
*/
public function boot()
{
// ...
}
/**
* Register any application services.
*/
public function register()
{
// ...
}
}
С точки зрения ООП, полиморфизма и всего такого, базовый класс ServiceProvider должен был бы содержать методы boot() и register(), пускай и пустые. И в нужный момент запускать `$provider->boot()`, не задумываясь, переопределён ли метод в потомке или нет.
Но этих методов в предке нет и вместо этого Laravel делает следующее (Illuminate\Foundation\Application):
protected function bootProvider(ServiceProvider $provider)
{
if (method_exists($provider, 'boot')) {
return $this->call([$provider, 'boot']);
}
}
И такое в очень многих местах.
Есть в этом какой-то смысл или скрытое преимущество?
Если это методы, наследуемые, от родительского класса, то лучше камменты не повторять каждый раз.
Я пишу в этом случае:
/**
* {@inheritdoc}
*/
Правда, к сожалению, я заметил, Laravel, почему-то не любит иметь базовые методы и вместо этого просто ищет метод через method_exists().
В этом случае какой-нибудь phpDocumentor может и сломаться о {@inheritdoc}
Мне не ясно, на вскидку, что такое dates и что такое guarded.
Только, к сожалению, далеко не всегда комментарии это доходчиво объясняют.
Поэтому моё скромное мнение — комментарии должны нормально и подробно описывать описываемое.
А если человеку это лениво, то лучше вообще не писать, чем делать отписки, просто потому что такой код-стайл.