Очень крутой и познавательный ролик.По поводу проектов, я скоро закончу производственную практику в колледже и пришлю вам проект на проверку вместе с отчётом . Думаю людям будет интересно посмотреть на ваш разбор проекта ,который одобрили в учебной организации
сделаем обзор на обзор )) 7:50 ну каммон ... у чела было /messages/roomId={id}, а у обозревателя почему то оно превратилось в /messages/{id}/room .... а должно было бы быть /messages/roomS/{id}... и id местами поменял и теперь оно относится не к комнатам а к сообщениям, и комнаты оставил в единственном. так что с такими ошибками оно стало не "лучше чем было" а стало явно хуже. 8:09 "в остальном наверное всё" ... да ладно ? кругом много в сингуларе вместо плурала ... ну или тогда всё в сингуларе без миксов, что то одно выбрать бы... а не смутил роут POST /chat/store ... как бы метод POSTнам и так говорит что будет создание чата, звчем там "store" ? а не смутил POST /messages/send который далее проименован как "store" ? send здесь в принципе не нужен, но еще и второй вопрос а какого лешего в одном случае сенд а во втором сторе ? потому что для уха звучит приятно ? а то что /messages/chatId={id} именован как messages.room a /messages/roomId={id} именован как messages.chat тоже не смутило ? у меня лично в голове диссонанс возник ... старнно это как то. GET /friends/confirm={id} - тоже что то странное ... что там внутри ? если получение списка ибо GET тогда /friends/{id}/confirmED, а если используется confirm то почему оно GET, потому что confirm звучит как команда на модификацию... тоже касается и GET /friends/add= GET /posts/create - это как ? если это получить список постов то тогда просто GET /posts а если именно созданные посты то правильный глагол юзать надо GET /posts/createD GET /posts/update/{post} - это что за зверь такой ? это как ? будем надеяться что в коде он ничего не апдейтит и это всё же на получение данных .. смею предположить что это может быть получение истории обновления поста... но чем бы это небыло ИДЕНТИФИКАТОР РЕСУРСА НАДО СТАВИТЬ ПОСЛЕ РЕСУРСА К КОТОРОМУ ОН ОТНОСИТСЯ GET /posts/{post}/updateS/ или GET /posts/{post}/history/ или еще как то хз что оно там делает. и еще сразу вопрос а чего миксуем в роутах {blabla_ID} и {model} ... почему не в одном стиле ? здесь всё очень просто и можно было бы выбрать один из стилей ... и это только по роутам в дополнение после твоего "в остальном нормально" -------------- по моделям. соглашусь про именование в единственном ... но сразу бы может и объяснил почему именно в единственном числе ? это не потому что "конвенция именования" и не потому что "что бы руками не прописывать название" а вот ответ на ПОЧЕМУ - лежит в понимании того что такое модель - это та самая теория которой автор не знает и путался в показаниях на собеседовании, а другой комментатор меня упрекнул "зачем ему знать эту устаревшую никому не нужную теорию - он практик"... НЕ соглашусь про то что имя таблицы если уж можно, то писать не нужно ... можно то оно можно, но лучше писать... потому что ненужная теория рассказывает нам о принципе "явное лучше неявного". программист скотина уставшая может что то и провтыкать особенно если таблицы будут названы как то одинаково, а в больших проэктах так оно и бывает... 10:20 "не люблю когда в одном месте называется так а в другом по другому" - правильные слова, но в роутах они тебя не насторожили ;) про внешние ключи и связь на уровне базы - это вопрос дискусионный ... связи в моделях сделать надо - как минимум для понимания что с чем связано даже если их не использовать в случае сложных запросов... а вот связь на уровне базы часто в крупных проэктах не используют потому что это иногда создает много гемороя, но индексы безусловно проставляем ... оно конечно очень хочется проставить связи что бы как минимум удаление на базу переложить... но бывает и так что в одной надо удалить а вот в других оставить для истории .... то есть вопрос дискусионный и рубить с плеча "НАДО ДЕЛАТЬ" показывает что автор не участвовал в крупных проэктах... 13:18 про миграции на добавление удаление полей ... у человека выработалась правильная привычка, так что ненадо его учить плохому. сам или не сам, дома или уже в проде - неважно, есть правильная привычка и это хорошо. было бы хуже если бы он как раз то менял миграцию начальную. 13:47 тип text для userId ... "таких мелочей много не буду по ним проходиться" нифига себе мелочь ... текстовое поле на user_id... это критическая ошибка а не мелочь! на этом поле и индекса даже не стоит, а если бы он стоял то это индекс по текстовому полю... может по этому и таблицы он связать не может что поля не совпадают а чел не понял в почему и из за чего и просто болт забил на связи в базе ... упрекнуть ты его упрекнул, а вот объяснить почему так не объяснил и назвал "мелочью" ... хрена себе мелочь ... дальше я забил смотреть... тому комментатору который под видео про устройство на работу и "нахрена ему ненужная теория, он практик" передаю привет, была бы теория небыло бы таких глупостей сказано в видео ...
По моему сейчас Laravel 10 при методах Update при генерации сама предлагает там id. Даже если генерация контроллера или ресурса были на основе модели. Он не инжектит туда модель. При strict моде он указывает, что передана не модель, а int. Я много у кого видел, что большинство прописывает {post} и в контроллере уже ловят этот (Post $post). Но так не работает почему-то, туда приходит цифра.
@@vetenskap1573 Я думал, что роут байндинг в любом случае срабатывает. Даже если я в контроллере с моделью не взаимодействую, а сразу передаю её во вьюшку. Но спасибо за замечание. Я потом и сам разобрался, но вызывает негодование до сих пор.
Привет, смотрю тебя за долго до начала моей работы в компании, а там уже я работаю год и 3 месяца (не сказать что полтара года, но и не мало). Мой наставник говорил, что хорошая практика использовать ресурсы, но конечно относится к api. Ещё читал статью паренька на хабре, не знаю кому как совет, я пока данную практику не применял, но хочу поделиться. Он писал, что для Eloquent логики использует репозиторий, тогда как бизнел логику прописывает в сервисах.
Использование репозиториев и сервисов в принципе очень правильное решение с точки зрения проектирования. При таком подходе контроллеры отвечают исключительно за контроль потока данных и больше ни за что. Получается примерно следующее: получили данные, валидировали, отдали репозиторию и/или сервису, получили оттуда какие-то обработанные данные (возможно) и сформировали ответ. В идеале чтобы данные валидировались в отдельном классе (автор видео об этом упоминал) и ответ тоже формировался отдельным классом (иногда можно без класса, если ответ предельно прост, но если нужно, например сформировать массив из моделей - то тут однозначно отдельный класс). Для чего этот, на вид бесполезный зоопарк классов, нужен: для того чтобы снизить объем ответственности каждого класса и тем самым уменьшить связность между классами. Фактически из 4х классов, которые используется в обработке запроса в контроллере, каждый из них практически не связан с другими. В итоге вы можете заменить/изменить любой из них не меняя логики других классов. Хороший класс - это класс, который имеет минимальную зону ответственности (выполняет минимальное кол-во задач) при минимальной связанности с другими классами.
Круто, а ты делаешь ревью на react проекты? У меня есть готовый проект на react и в качестве бэка на laraval сделал апишку чисто. Я новичек и впервые с такими инструментарием дошел до прода
Это, действительно, спорное выражение у автора. Потому что при необходимости понять, с какой таблицей связана модель - это очень удобно, если название таблицы указано в модели. В больших проектах, где около 100-200 миграций (проект живет и развивается) без указания таблицы в модели - найти очень и очень сложно и долго. Тем более, если есть модели, которые называются одинаково, только находятся в разных namespace.
Роутинг постов можно переделать на ресурсы. Как-то странно, что вместо метода put для обновления используется метод get со словом update в адресе - так себе практика, учитывая, что существуют ресурсы
добавлять префикс маршрутам плохая практика, да это сокращение, но поиск нужного маршрута усложняется, через поиск уже не найти нужный роут, так как он "разбит".
Типичный проект, когда делаешь всё по документации в первый раз. Бест практик ещё не знаешь, поэтому следуешь рецептам из доков. Итого: парню за то что смастерил сам без посторонней помощи работающий проект 5 баллов и еще 5 за то что не ссыкнул и прислал его на проверку на всеобщее обозрение
@@Фанат-щ9ь у автора кода нету наполнителей базы данных, для него стало быть, трудозатратно удалить базу и создать ее снова, с дополнительными полями. Поэтому он вносит доп поля в уже готовую базу, будто это работающий проект
@@Фанат-щ9ь я тоже без понятия, что он имел ввиду. seeders - это какой-то набор готовых данных, которые кладутся в базу данных после запуска команды раскатить сиды. но это чаще всего имеет смысл, когда ты сносишь всю БД или разворачиваешь с нуля. добавление новых полей в миграций не вызывает удаление таблиц.
@@Фанат-щ9ь Автор видео все правильно говорит, нет смысла делать отдельные миграции на добавление нескольких новых полей вместо добавления этих полей в уже существующую миграцию, если это собственный проект, над которым работаешь только ты. А изменить несколько строк кода в сидах не много работы.
@@Фанат-щ9ь 7 месяцев прошло, но вдруг тебе до сих пор интересно)))))))000)00))0) Это сарказм, что еще и seeders пришлось бы переписывать, если миграции переписываешь))
Очень крутой и познавательный ролик.По поводу проектов, я скоро закончу производственную практику в колледже и пришлю вам проект на проверку вместе с отчётом . Думаю людям будет интересно посмотреть на ваш разбор проекта ,который одобрили в учебной организации
Будет интересно глянуть, ждем
ну че там с проектом?
Не знал, что можно задавать префикс для названий роутов (через метод as()), спасибо!
Лучше так не делайне. При росте приложения, найти нужный роут становится сильно сложнее, если имя маршрута разбито между группами и роутом
Отличный разбор. Очень полезно
сделаем обзор на обзор ))
7:50 ну каммон ... у чела было /messages/roomId={id}, а у обозревателя почему то оно превратилось в /messages/{id}/room .... а должно было бы быть /messages/roomS/{id}... и id местами поменял и теперь оно относится не к комнатам а к сообщениям, и комнаты оставил в единственном. так что с такими ошибками оно стало не "лучше чем было" а стало явно хуже.
8:09 "в остальном наверное всё" ... да ладно ?
кругом много в сингуларе вместо плурала ... ну или тогда всё в сингуларе без миксов, что то одно выбрать бы...
а не смутил роут POST /chat/store ... как бы метод POSTнам и так говорит что будет создание чата, звчем там "store" ?
а не смутил POST /messages/send который далее проименован как "store" ? send здесь в принципе не нужен, но еще и второй вопрос а какого лешего в одном случае сенд а во втором сторе ? потому что для уха звучит приятно ?
а то что /messages/chatId={id} именован как messages.room
a /messages/roomId={id} именован как messages.chat
тоже не смутило ? у меня лично в голове диссонанс возник ... старнно это как то.
GET /friends/confirm={id} - тоже что то странное ... что там внутри ? если получение списка ибо GET тогда /friends/{id}/confirmED, а если используется confirm то почему оно GET, потому что confirm звучит как команда на модификацию...
тоже касается и GET /friends/add=
GET /posts/create - это как ?
если это получить список постов то тогда просто GET /posts
а если именно созданные посты то правильный глагол юзать надо GET /posts/createD
GET /posts/update/{post} - это что за зверь такой ? это как ?
будем надеяться что в коде он ничего не апдейтит и это всё же на получение данных ..
смею предположить что это может быть получение истории обновления поста... но чем бы это небыло ИДЕНТИФИКАТОР РЕСУРСА НАДО СТАВИТЬ ПОСЛЕ РЕСУРСА К КОТОРОМУ ОН ОТНОСИТСЯ
GET /posts/{post}/updateS/ или GET /posts/{post}/history/ или еще как то хз что оно там делает.
и еще сразу вопрос а чего миксуем в роутах {blabla_ID} и {model} ... почему не в одном стиле ? здесь всё очень просто и можно было бы выбрать один из стилей ...
и это только по роутам в дополнение после твоего "в остальном нормально"
--------------
по моделям.
соглашусь про именование в единственном ... но сразу бы может и объяснил почему именно в единственном числе ?
это не потому что "конвенция именования" и не потому что "что бы руками не прописывать название"
а вот ответ на ПОЧЕМУ - лежит в понимании того что такое модель - это та самая теория которой автор не знает и путался в показаниях на собеседовании, а другой комментатор меня упрекнул "зачем ему знать эту устаревшую никому не нужную теорию - он практик"...
НЕ соглашусь про то что имя таблицы если уж можно, то писать не нужно ... можно то оно можно, но лучше писать... потому что ненужная теория рассказывает нам о принципе "явное лучше неявного". программист скотина уставшая может что то и провтыкать особенно если таблицы будут названы как то одинаково, а в больших проэктах так оно и бывает...
10:20 "не люблю когда в одном месте называется так а в другом по другому" - правильные слова, но в роутах они тебя не насторожили ;)
про внешние ключи и связь на уровне базы - это вопрос дискусионный ...
связи в моделях сделать надо - как минимум для понимания что с чем связано даже если их не использовать в случае сложных запросов...
а вот связь на уровне базы часто в крупных проэктах не используют потому что это иногда создает много гемороя, но индексы безусловно проставляем ... оно конечно очень хочется проставить связи что бы как минимум удаление на базу переложить... но бывает и так что в одной надо удалить а вот в других оставить для истории .... то есть вопрос дискусионный и рубить с плеча "НАДО ДЕЛАТЬ" показывает что автор не участвовал в крупных проэктах...
13:18 про миграции на добавление удаление полей ...
у человека выработалась правильная привычка, так что ненадо его учить плохому.
сам или не сам, дома или уже в проде - неважно, есть правильная привычка и это хорошо.
было бы хуже если бы он как раз то менял миграцию начальную.
13:47 тип text для userId ... "таких мелочей много не буду по ним проходиться"
нифига себе мелочь ... текстовое поле на user_id... это критическая ошибка а не мелочь!
на этом поле и индекса даже не стоит, а если бы он стоял то это индекс по текстовому полю...
может по этому и таблицы он связать не может что поля не совпадают а чел не понял в почему и из за чего и просто болт забил на связи в базе ... упрекнуть ты его упрекнул, а вот объяснить почему так не объяснил и назвал "мелочью" ... хрена себе мелочь ...
дальше я забил смотреть...
тому комментатору который под видео про устройство на работу и "нахрена ему ненужная теория, он практик" передаю привет, была бы теория небыло бы таких глупостей сказано в видео ...
Вам не было лень писать всё это ?😅
@@ramazanstudy570
Нет не лень... Автор же хочет чему-то научить... Поэтому ученикам надо помочь научиться чему-то хорошему а не плохому
@@onlybestmusic4185 в таком случае, вы можете помогать мне 😅😂
Какой крутой и развернутый разбор, лучше чем на видео. Может можно вам свой проект на разбор отослать? 👉👈
Спасибо за видео. Супер формат!
А как шрифт называется в IDE, который в видео используется?
Доброго времени суток! Написал проект на ларавел, отправил на ревью по ссылке. Подскажите, сможете рассмотреть? Просто интересно услышать критику)
Room All там судя по ифам в цикле нужно было использовать where что бы найти чаты текущего юзера
привет, не подскажите название приложения на фоне в начале? в котором можно кодить? или это vs code?
phpStorm
PHPStorm 2023 года с новым UI
@@alexeysamoilik6481 спасибо а там сразу есть что-то типо опен сервера или его качать надо все равно? и там есть ли уже пхп сразу?
А можно кидать проекты в стадии разработки? Со списком вопросов например
По моему сейчас Laravel 10 при методах Update при генерации сама предлагает там id. Даже если генерация контроллера или ресурса были на основе модели. Он не инжектит туда модель. При strict моде он указывает, что передана не модель, а int. Я много у кого видел, что большинство прописывает {post} и в контроллере уже ловят этот (Post $post). Но так не работает почему-то, туда приходит цифра.
Модель инжектится при использовании. То есть если в контроллере вызвать у модели, к примеру, метод update, то всё нормально отработает
@@vetenskap1573 Я думал, что роут байндинг в любом случае срабатывает. Даже если я в контроллере с моделью не взаимодействую, а сразу передаю её во вьюшку. Но спасибо за замечание. Я потом и сам разобрался, но вызывает негодование до сих пор.
Привет, смотрю тебя за долго до начала моей работы в компании, а там уже я работаю год и 3 месяца (не сказать что полтара года, но и не мало). Мой наставник говорил, что хорошая практика использовать ресурсы, но конечно относится к api. Ещё читал статью паренька на хабре, не знаю кому как совет, я пока данную практику не применял, но хочу поделиться. Он писал, что для Eloquent логики использует репозиторий, тогда как бизнел логику прописывает в сервисах.
Использование репозиториев и сервисов в принципе очень правильное решение с точки зрения проектирования. При таком подходе контроллеры отвечают исключительно за контроль потока данных и больше ни за что. Получается примерно следующее: получили данные, валидировали, отдали репозиторию и/или сервису, получили оттуда какие-то обработанные данные (возможно) и сформировали ответ. В идеале чтобы данные валидировались в отдельном классе (автор видео об этом упоминал) и ответ тоже формировался отдельным классом (иногда можно без класса, если ответ предельно прост, но если нужно, например сформировать массив из моделей - то тут однозначно отдельный класс). Для чего этот, на вид бесполезный зоопарк классов, нужен: для того чтобы снизить объем ответственности каждого класса и тем самым уменьшить связность между классами. Фактически из 4х классов, которые используется в обработке запроса в контроллере, каждый из них практически не связан с другими. В итоге вы можете заменить/изменить любой из них не меняя логики других классов. Хороший класс - это класс, который имеет минимальную зону ответственности (выполняет минимальное кол-во задач) при минимальной связанности с другими классами.
Подскажите пожалуйста где можно почитать информацию как писать приложение для андроид с использованием сервера mysql
напиши мне в личку у меня много инфы по разработке на андроид
@@МаксимИващенко-л5о в личку куда? Почты или ссылку дайте
куда кидать свой проект, что автор его проверил?
Отличный формат))
Круто, а ты делаешь ревью на react проекты? У меня есть готовый проект на react и в качестве бэка на laraval сделал апишку чисто. Я новичек и впервые с такими инструментарием дошел до прода
По-моему, эти vue-компоненты из какого-то стартового набора, поэтому не разложены по папкам
А я встречал совет что в моделях нужно всегда прописывать имя таблицы даже если оно создано по конвенции и не требуется
Это, действительно, спорное выражение у автора. Потому что при необходимости понять, с какой таблицей связана модель - это очень удобно, если название таблицы указано в модели. В больших проектах, где около 100-200 миграций (проект живет и развивается) без указания таблицы в модели - найти очень и очень сложно и долго. Тем более, если есть модели, которые называются одинаково, только находятся в разных namespace.
Роутинг постов можно переделать на ресурсы. Как-то странно, что вместо метода put для обновления используется метод get со словом update в адресе - так себе практика, учитывая, что существуют ресурсы
добавлять префикс маршрутам плохая практика, да это сокращение, но поиск нужного маршрута усложняется, через поиск уже не найти нужный роут, так как он "разбит".
Спасиб за видос. Ты только php ревью делаешь? Как насчёт js?
Работает удаление, когда передаешь в параметре чисто {post} Лара сама резолвит id
Здравствуйте, не хотите сделать обзор на October cms?
На самом деле весь этот код (за исключением breeze и кода от Laravel Creative) - отличный пример того как делать НЕ надо
Все начинают с чего-то
Типичный проект, когда делаешь всё по документации в первый раз. Бест практик ещё не знаешь, поэтому следуешь рецептам из доков. Итого: парню за то что смастерил сам без посторонней помощи работающий проект 5 баллов и еще 5 за то что не ссыкнул и прислал его на проверку на всеобщее обозрение
Внешний ключ, не вторичный :)
13:00 слишком жирно переписывать миграции) Что бы потом руками базу данных по новой заполнять?)) Ну думаю отсылочку с seeders поняли)
Просветите пожалуйста, не совсем понял к чему ведёт намёк))
@@Фанат-щ9ь у автора кода нету наполнителей базы данных, для него стало быть, трудозатратно удалить базу и создать ее снова, с дополнительными полями. Поэтому он вносит доп поля в уже готовую базу, будто это работающий проект
@@Фанат-щ9ь я тоже без понятия, что он имел ввиду. seeders - это какой-то набор готовых данных, которые кладутся в базу данных после запуска команды раскатить сиды. но это чаще всего имеет смысл, когда ты сносишь всю БД или разворачиваешь с нуля. добавление новых полей в миграций не вызывает удаление таблиц.
@@Фанат-щ9ь Автор видео все правильно говорит, нет смысла делать отдельные миграции на добавление нескольких новых полей вместо добавления этих полей в уже существующую миграцию, если это собственный проект, над которым работаешь только ты. А изменить несколько строк кода в сидах не много работы.
@@Фанат-щ9ь 7 месяцев прошло, но вдруг тебе до сих пор интересно)))))))000)00))0) Это сарказм, что еще и seeders пришлось бы переписывать, если миграции переписываешь))