Alex Wells

https://laravel.com/docs/5.8/views#sharing-data-wi...
Cоздаешь провайдер и шаришь в нем переменную с имейлом, а в футере просто выводишь

Ты в шаблон не передаешь переменную $user_Id из контроллера

Как сделать так, чтоб ... переходить

https://laravel.com/docs/5.8/redirects

условие @if влияет только на то, виден html или нет.

Вы неправы.

Картинки - это коллекция, она никогда не будет равна null, поэтому проверка ваша всегда проходит. Должно быть так:
@if($post->images->isNotEmpty())

$post->images()->first()->path

А вот здесь вы делаете лишний запрос в БД. Должно быть так: $post->images->first()->path

Тут (bytenode)
Защита приложения

это простейший sql запрос
https://www.w3schools.com/sql/sql_insert_into_sele...

lovebarcafc,

но блин создавать посредника, объявлять его и далее подключать, не совсем уместно для передачи одного не сложного параметра

А если таких параметров больше? И контроллеров, в которых это делается тоже больше 1? Смысл middleware в том, что его можно применить массово из одного места - на все роуты, только апи, консоль или веб, группу роутов... Вот например я пишу АПИ для iOS приложения, и хочу быть уверен, что все запросы на мои роуты содержат заголовок Content-Type: application/json. Запилить под это middleware - самое оно.

Middleware следует воспринимать не как из примера в доке с возрастом, а как слои, через которые request и response проходят. Request входит в приложение и пропускается через ряд "фильтров" (middleware), потом то же самое происходит с response.

1. Адекватность и самостоятельность.
Детальнее: Умение понять суть задачи, чтобы выполнить ее. Самостоятельно решать проблемы - в это слово входит не только то, что возникла проблема - порешал. А умение решить проблемы, которые ты решить не можешь. То есть организовать решение проблемы. Заблочили аккаунт? Выяснить, вызвонить, попинать, чтобы разлочили побыстрее. Не знаешь как решить какую-то техническую проблему - достучаться до куратора. Не сидеть и ждать три дня, пока он вспомнит про твою проблему, а регулярно уточнять. Занят куратор - подойти к другому. Не успеваешь решить в срок - прийти к куратору заранее, а не за час до конца срока.
В общем, чтобы за тобой не бегали.

2. Умение ставить правильные вопросы.
Сперва загуглить, потом задать вопрос для уточнения. В идеале ставить вопросы, на которые ответ будет "да" или "нет", но это я утрирую. Не бояться спрашивать вещи, которые совсем не понимаешь, но тут не нужно ожидать что все будут разжевывать - следует задать вопрос, чтобы понять куда копать. Иногда достаточно знать пару ключевых слов, по которым можно загуглить.

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

Правильно ли я думаю

Да.

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

Невозможно в разработке планировать какие-либо сроки. Тут автор прав.

Ответ на самом деле очень простой - ты работаешь на весьма хреновой работе. Я сейчас опять пропиарю свою статью про выживание в IT, прочти её, там не касается полностью твоего вопроса, но суть очень близка (пожалуй, я потом её дополню, спасибо за "наводку" - про сроки я там не писал...).

Как оценивать сроки? Ответ очень простой - да никак не оценивать. Если работодатель построил такую систему, где менеджмент лезет с этими бюрократическими вопросами, не понимает, что разработка или фикс багов в проекте - это не типовая работа, как, например, класть кирпичи или валить лес - то это плохой работодатель. Или плохой менеджмент. А в целом - это компания-эксплуататор, из которой надо бежать.

Я по себе знаю, когда от меня требовали сроки. Последний раз был вообще трешачок в одной московской компании - от меня требовали сроки на 2 день после назначения задачи на меня, при этом я вообще не понимал ничего в задаче - в её бизнес-логике, т.к. работал в этой компании от силы недели три. Через буквально несколько дней меня вызвали "на ковер", мол, почему так долго. Жалею, что прямо тогда не послал их прямым текстом на три известные буквы, а продолжил работать. Ничего хорошего из этого, конечно же, не вышло.
Сейчас я работаю в таком месте, где ВООБЩЕ нет никакого понятия сроки, где разработка проектов в корпорации длится годами - IT работает не на внешнего заказчика, а на внутреннего - на саму же корпорацию. Последний проект, в котором я участвовал, занял около 2-х лет. И бОльшая часть была не программинг, а взаимодействие разных отделов, нахождение багов, форсмажорных ситуаций после запуска и т.д. Работать в таких условиях сплошное удовольствие. Никаких стрессов, никаких менеджеров, изображающих бурную деятельность.

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

Лучшая практика описана в документации.