Pull to refresh

Comments 96

composer.lock разве должен быть в списке ignore? Ведь он дает гарантию что у всех стоят одинаковые версии и если кто нибудь обновился, то об этом узнают остальные участники.
По этому вопросу не читал информации. Замечал лишь что когда проект из репы себе загружаешь и выполняешь `composer update` — файл перезаписывается. Вот и исключил его из выгрузки в репозиторий.
Это фиксатор версий, он должен быть обязательно под git. Как уже сказали сразу будет видно кто и когда обновил набор утилит.

Замечал лишь что когда проект из репы себе загружаешь и выполняешь `composer update`

а надо делать `composer install` и тогда если в репе есть composer.lock версии пакетов будут поставлены в соответствии с его содержанием, то есть они будут идентичны для всех участников проекта.

PS: статью не читал ибо настраивать окружение каждый раз и использовать опенсервер это как то лениво. Проще запилить свой кастомный vagran\docker.
У меня нет опыта работы с git в команде. Использую у себя для «переноса» исходников из дома на работу и обратно, попутно смотрю что когда сделал.
Спасибо за объяснение, статью поправил.
еще посмотри laragon.org это вместо openserver. по мне он лучше
Судя по строке на лоадере при открытии страницы, в нем есть Apache 2.4, MariaDB 10.1, PHP 7.0 & 5.6 и NodeJS 5.10.
По факту, в нем есть PostgreSQL 9.5, Redis 3.0, Nginx 1.10+?

А то на странице кроме двух кнопок скачать ничего не нашел.
Извини, но если нет серьёзного опыта, зачем писать 100500 статью для новичков. Тем более в ней 100500 вредных советов вроде open server вместо homestead, кривой gitignore, бесполезный и вредный whoops, который только мешает отдалке и т.д.
Про Homestead указано в статье, как и то, что кому что нравится — тот тем и пользуется. Лично мне он удобен.
По gitignore можно расширенный комментарий с фактами? Почему он «кривой»? Что не так? Как правильно?

Бесполезный и вредный Whoops? Вот это новость) На мой взгляд, таковым его будут считать те, кто пользоваться не умеет. Лично мне он очень помогает, в отличие от стандартного.

Убедительная просьба комментировать свой негатив, указывая факты и как бы Вы сделали. Просто поливать не есть конструктивно. Это лишь захломляет страницу спамом, не более.
Честно говоря, не вижу особого смысла расписывать ответ для человека, который разработывает под виндой и не знает основ composer и требований к коммерческой разработке. Но раз хотите:

Из-за из-за опенстека на продакшене потом вылазят баги вроде регистра в названии файлов
Про гитигнор вам уже писали в комментах — composer.lock нельзя игнорить с него разворачивает проект т.к. там зафиксированы версии, игнорится папка public в которой помимо будут лежать ещё 100500 иконок для мобильных девайсов и для сеошников
Whoops лишь видеозменяет вывод ошибки, при этом добавляет свои, потому ещё и выбросили в новых версиях из laravel, загляните в баг трекеры.

По Вашему мнению, работать под виндой — плохо?
Знаете, не Вам судить какую ОС предпочитает тот или иной разработчик.

Легко сказать «плохо», вот только информативность такого «сообщения» нулевая.
Сейчас Вы уже по факту объяснили свою позицию — это уже интересная беседа.
Дело не в том какую ОС предпочитает разработчик, а то, на какой ОС будет крутиться проект, в 99% это unix. Соотвественно, разрабатывая на винде, нужно ставить виртуалку, чтобы не было проблем. Да и на линуксах тоже, чтобы енвайромент был одинаковым с продом.

Я активно помогаю по laravel, на тостере, на формумах и т.д., описаные проблемы очень типичны, потому что в интернете 100500 статей по laravel, которые написаны новичками. При том что есть хорошая дока и ларакаст.
сам же виндовозом был и злобным линуксоненавистником, не?
винда на декстопе, линукс на сервере. не вижу противоречий.
А меня кусаете за то, что работаю под виндой.
Хотя ситуация такая же — винда на десктопе и линух на сервере.
Какой линукс на сервере, когда вы вопреки рекомендациям документации laravel советуете людям openserver.
Читаем статью внимательнее:

Да, кто-то скажет что фреймворк имеет Homestead в качестве виртуальной машины. Отвечу лишь, кому как удобно. Лично мне удобен OpenServer под «виндой».

Разработка у меня исключительно под виндой, а на продакшн-сервере линух установлен. Что тут непонятно-то?

И, к тому же, я ничего не советую. так и пишу — кому на чем, а мне на этом.
Здесь же дело не в удобстве, а в разном функционале при работе под windows и linux, из-за которого ваш проект может вовсе НЕ РАБОТАТЬ под другой операционной системой.
Теоретически, может. На практике, лично ни разу не сталкивался — всегда работали проекты. Клиенты не жаловались.
Так ежик, вы даже с гитом в команде не работали, какой к чёрту опыт. Первая же проблема которая вылезет при переносе после вашей статьи — это права на файлы. И человек бежит на форумы спрашивать, ведь он же статью прочитал, зачем ему доки, если если человек с опытом так написал.
На оскорбления переходите? Негоже это.
По-вашему, «опыт» — это работать с гитом в команде? Имхо, это приятная мелочь при разработке и, к тому же, крайне полезная.

Вот вам встречная ситуация: на десктопе и сервере линукс. Работаем под одной системой с одними правами. Приходит Дед Лайн и выгружаем на сервер в продакшн — там другая система с другими правами. Результат: что из-под винды выгружать в линух, что с линуха в линух — суть-то та же остается. И точно также человек в гугл рванет за решением.

Так что какой смысл хаять выбор человека под чем работать?
Где вы увидели оскорбления?

Про вашу ситуацию я сказал выше https://habrahabr.ru/post/309568/?reply_to=9798148#comment_9797974 Даже под линуксом нужно разрабатывать в той же среде, что будет на проде.
Так ежик,...

Я расцениваю это как оскорбление в мой адрес.

А по поводу разработки, как и писал раннее, лично у меня ни разу проблем не было с выгрузкой файлов на продакшн-сервер. Единственное, никогда под рутом не заливал файлы — вот и весь секрет.
Вот видите, почему важно давать точную информацию, а не рассчитывать на понимание новичками контекста.
UFO just landed and posted this here
После того как из репы загружаешь проект, надо делать 'composer install' в таком случае при наличии composer.lock устанавливаются именно те версии что указаны в composer.lock. В случае же 'composer update' можно попасть на неожиданное обновление и долго думать что же поломалось.
UFO just landed and posted this here
Есть хороший ответ на SO по этому поводу http://stackoverflow.com/a/24247443.
Кратко: при разработке приложения определённо стоит коммитить lock-файл, чтобы в любой момент разворачивать приложение с теми же самыми зависимостями что и в прошлый раз; при разработке библиотеки – необязательно, потому что при включении библиотеки в проект её lock-файл будет игнорироваться проектом.

А по поводу install/update – придерживаюсь такого принципа, что всегда надо делать composer install. Если есть lock-файл, будет установка конкретных версий, если нет lock-файла, то будет установка актуальных версий. composer update стоит делать тогда и только тогда, когда преследуется цель именно обновить версии пакетов в lock-файле.
>> чтобы в любой момент разворачивать приложение с теми же самыми зависимостями

Да что там, еще и с теми же самыми версиями, один в один во всех окружениях.
Хочу заметить что для новичков это все равно бесполезно. Ну то есть инструкция то конечно хорошая и подробная, но основной вопрос который возникает у новичков по каждому компоненту — «что это вообще такое и для чего оно используется». Когда становится понятно «что это», вопрос «как установить» уже решается простейшим гуглением.
Зачем Гугл, если есть Хабр? ;)

Всё решается простейшим хабрением?)

Новичок новичку рознь, как говорится.
Лично у меня, несколько лет назад, при изучении данной темы и вообще фреймворка (тогда и узнал что такое композер), также кратко нашел в англоязычном сегменте инструкции, и был лишь вопрос «как использовать?», а вопрос «что это и для чего?» крайне редко возникал — по ходу дела ответ сам находился.
Вопрос «что это» предполагает глубокое осмысление сути, понимание устройства и архитектуры современных веб приложений.

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

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

БЫДЛОКОДЕРЫ, ОСТАНОВИТЕСЬ!!!1

давайте разбирать, правда у меня куда-то пропал редактор с неудобными кнопками цитирования, так что буду так писать в кавычках

«Установка Laravel 5.3
Перед началом разворачивания фреймворка убедитесь, что на компьютере установлены утилиты Composer и NodeJS.»

т.е. для установки пхп фреймворка мне надо установить еще 100 мегабайт яваскрипта?

«На сайте sass-lang.com находим ссылку на Ruby Installer — жмем ее и качаем установочник, тыкая в большую красную кнопку. Устанавиваем, перезагружаем компьютер.»

т.е. для писания цсс мне надо установить еще почти 100 мегабайт руби? только для того, чтобы собирать цсс из исходников?

«Далее, в файле `config/app.php` добавляем сервис-провайдер `Barryvdh\LaravelIdeHelper\IdeHelperServiceProvider::class,` в блок `providers`.»

что мне это дает?
мануал в стиле «делай а, делай б» зачем? так надо!!!

«Давно перешел с CSS-фреймворка Twitter Bootstrap в пользу «материального» дизайна MaterializeCSS, поэтому заходим на сайт и качаем исходники для `SASS`.»

и чем он лучше? я посмотрел — как будто стили поменяли и контролы выглядят по-другому
были привычные кнопки, чекбоксы и все такое, теперь непонятно что и даже не видно границ рамок полей ввода

«Собственно, вот и все.
Приятного пользования.»

спасибо, не надо
— этот ваш веб катится в сраное гавно, вы уже засрали все что можно, извратили и испоганили так, что мощный 4х ядерный процессор не может переварить все эти нагромождения и браузер падает
вчера не мог зайти в онлайн магазин — браузер тупо падает при включении яваскриптов, а потом владелец магазина сидит и думат: сайт сделали крутой, в рекламу вбухиваю, а клиентов нет

короче реально уже достали
вы уже засрали все что можно

ну зачем так категорично?
что мощный 4х ядерный процессор не может переварить все эти нагромождения

напоминает знакомый плач админов на тему «великой и могучей программы 1С»

NodeJS обеспечивает работу Elixir. Без него невозможно это реализовать. В статье есть ссылка что такое Эликсир. Почитайте.

т.е. для писания цсс мне надо установить еще почти 100 мегабайт руби? только для того, чтобы собирать цсс из исходников?

А ты вручную будешь конвертировать SASS в CSS?
Это мне?) Вроде как про Эликсир не я хай поднимал)
Наоборот, использую его вовсю уже давно)
Я про то, что зачем ставить Ruby?
Возможно, это у меня ошибка такая была, но еще со времен 5.1, когда начал пользоваться SASS, эликсир выдавал ошибку без предустановленного node-sass, который выдавал ошибку без руби, скачанного с сайта sass-lang.com.
Может это и исправили, но я не проверял. Делаю как привык.
Если вы не сделаете компиляцию принудительно с помощью Ruby, то он не нужен. Компиляция по-умолчанию выполняется Libsass, который подключается через node-sass, который подключается через gulp-sass, который подключается через laravel-elixir.
Вроде все понял. На досуге пересмотрю свой взгляд на эту тему.
Чую, до этого на костылях сидел)
Спасибо!
ты сидел на костылях и даже не замечал этого?
а мне это глаза режет

если есть артизан, то он должен уметь собирать хотя бы цсс, ладно уж там яваскрипт оставим
я вообще думал, что для сборки сас есть софт под виндовс или плагин для иде типа пхпшторм
К сожалению, не замечал. Как-то привык.
Не должен artisan собирать ни стили, ни скрипты, ни картинки пережимать и т. д. Он для backend. Работа с frontend это нода уже давно и прочно. Вот руби в этом стеке лишний конечно.
Materialize стоило подтянуть через npm, а не идти и качать с сайта.

Так-то оно правильно, да лично у меня сложность возникает с разворачиванием репы на новом месте — так он вместе с репой подтянется, а через npm его дополнительно подтягивать нужно.
Пытался на него шторм натравить, но он его не видит и на новом месте также приходится хоть вручную, хоть через шторм его выкачивать.

Может это я чего-то еще не знаю, но, пока что, делаю как умею.
Не понял, какие трудности? прописываете зависимость в package.json и всё. Но ставить то конечно надо будет `npm i`. Вы же вендорный php код тоже не храните в репе и делаете `composer inst`.
Вчера чистый проект поднял и подтянул materialize-css через npm. Версия что в npm, что на сайте — 0.97.7, НО при подключении из репы вылезает ошибка в консоли — «Vel function not found», а при загрузке «вручную» файла с офф сайта — все норм.
А так да, раньше я как-то делал неправильно. С репы лучше загружать.
Последний аргумент сбил с ног. Как он вообще взаимосвязан с предыдущими пунктами? Какая взаимосвязь рабочего окружения разработчика и финального результата?
прямой нет конечно
но я тут показал, как автор написал про пхп фреймворк для новичков, а получилось так, что новичку чтобы начать работать с пхп и писать какое-то приложение — надо установить 100500 костылей и непонятно зачем они нужны

создается такое впечатление, что один идиот не понял, как что-то делать просто и придумал свой костыль
потом другой идиот выдумал еще один костыль и к нему костыль
это я про сас
цсс усложнили настолько, чтобы для того чтобы писать цсс надо выдумать сас, а чтобы из сас получить цсс надо еще компилятор

на стороне разработчика получается целая куча разного хлама, чтобы этим хламом сделать сайт, который будет валить браузер

вот это круто, вот это уже даже не надо, это пикотехнологии веб 3.0
Вы всерьез считаете что препроцессоры(и постпроцессоры?) для css придумали и используют «идиоты которые не поняли, как и что делать просто»?
именно так
раньше же как-то писали без всяких сас? писали
чего сейчас не могут? хотели облегчить? ну и дальше классика: хотели как лучше, а получилось как всегда

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

на хабре с дизайном намудрили что-то и 2-3 вкладке на хроме в андроиде и хром падает
планшет куплен в 2012 году с гигом озу
раньше вкладок 5 откроеш и читаеш себе

или сайт с виду простенький, чистенький дизайн, а за собой тянет мегабайт скриптов и шрифтов только потому, что где-то надо было поставить пару иконок из шрифтов
Зачем нам вообще компьютеры, машины, дома? Раньше же люди как-то жили в пещерах, прикрывались листиками и бегали с дубинками за разным зверьем…

Ебей, лично у меня грузится ровно за 4 секунды с включенными adBlock, adBlock Plus, Ghostery и Kaspersky Protection при том, что комп не сказать что быстрый — лично мне за глаза хватает.

Вот пруф




По поводу Хабры с дизайном…

Вот главная страница

Вы показываете просто свою некомпетентность. Причем тут те мнимые (потому как я не вижу у себя таковых и доказательств в виде таймлайнов загрузки и т.п. я не вижу) тормоза описанных вами сайтов и препроцессинг css?
раньше же как-то писали без всяких сас? писали
чего сейчас не могут?

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

раскладываю последовательно в логическую цепочку

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

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

т.е. усложнили жизнь путем ввода ненужной сущности «мобильный сайт»
в 100 раз усложнили цсс, потому что теперь надо писать их под разные размеры экранов и естественно это потянуло автоматизацию стилей

теперь нам надо выучить синтаксис и трюки написания стилей, чтобы улучшить производительность труда
это легко, когда ты до этого 5 лет каждый день писал стили, а ты представь себе человека, который с нуля входит? да у него мозги разорвет

и вот этот огромный один файл цсс на 200к подгружается и парсится браузером, занимая кучу времени
а там еще подгружается шрифт какой и яваскрипты фреймворка
и вот уже хром на планшете сожрал все озу и был прибит системой

делали сайты для мобильных платформ, а они там рушат браузер, потому что делатель тестировал не на планшете, а на десктопе путем изменения размера окна браузера
в лучшем случае на новом ифоне

теперь понятно, как сас привел к падению браузера?

«доказательств в виде таймлайнов загрузки»
при чем тут время загрузки? я говорю о времени отрисовки и ощущениям тяжести
я могу ощущать эту тяжесть при прокрутке страницы и в 2003 тот же ебей грузился сразу на скорости меньше мегабита и точно так же как и сегодня — тогда там покупали и продавали

сейчас при аукционах проходит куча времени, прежде чем запрос уйдет на сервер и нельзя даже близко прикинуть время и либо слишком рано накинул или уже аукцион закончился и все потому что отрисовка страницы стала медленная

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

Условно зададим блокам белый фон

CSS:
.div1 {
    background-color: #ffffff;
}

.div2 {
    background-color: #ffffff;
}

.div3 {
    background-color: #fffff1;
}


SASS:
$background-color: #ffffff;

.div1 {
    background-color: $background-color;
}

.div2 {
    background-color: $background-color;
}

.div3 {
    background-color: $background-color;
}

Предложу альтернативный вариант на Sass:


$background-color: #fff;
@for $i from 1 through 3 {
  .div#{$i} { background-color: $background-color; }
}
Статья вроде бы для новичков.
Вы описываете, что Вы делаете и как Вы это делаете.
Но не описываете для чего все это делаете.
Т.е. новички поставив все по вашему мануалу потом долго будут думать «что со всем этим делать».
Когда я начинал изучение этого фреймворка, на дворе появился 5.0. Мануалов на русском языке практически не было на тот момент.
Когда смотрел практические видеоуроки, зная технический английский, быстро разобрался что к чему. Причем, продолжительность многих уроков, как правило, не превышает 3-5 минут.
После наши российские разработчики выкладывали почти то же самое на русском языке. В среднем, ролики длятся 10-20 минут, НО после просмотра половины таких роликов в голове мысли: «что это вообще было?», «зачем потратил столько времени впустую, если ответ на вопрос так и не нашел?».
Да, российский люд больше воды лить любит (не все, но все же).

Исходя из этого, при написании статьи и опирался на практику, а не на теорию. Кому надо будет — погуглят консольные команды да названия, учитывая что краткое описание, все же, я предоставил, как и ссылки на подробное описание.
Лара в принципе довольно легко изучается, особенно при использовании Laracast.
И начинал работать приблизительно в то же время, что и Вы.
Но как мне кажется в статье для «новичков» должно быть описание «для чего», иначе это уже не статья для новичков, а просто мануал по установке конкретных модулей.
Люди, пишущие любые инструкции, отчасти выступают в роли учителей. Ведь, инструкции чему-то же учат.
Как известно, учителя делятся на два типа: теоретики и практики.
Первые подробно объясняют что откуда взялось, за что отвечает, для чего нужно и как использовать. Вторые же, в основном, опираются на практический опыт, т.е. — вот вам факт и его нужно использовать так-то. Минимум теории.
Я отношусь ко второй группе.

На совершенство статьи и не претендовал. В статье почти «сухие» действия, коих, на мой взгляд, достаточно для общего представления действий.
Люди, которым мало изложенного в тексте, могут перейти по прикрепленным ссылкам, где уже теоретики написали инструкции с подробным описанием что-откуда-куда-зачем.

У меня несколько вопросов:
1) Зачем ставить openserver, когда достаточно php и встроенного сервера в него?
2) Зачем public и composer.lock в ignore?
2.1) Почему там же _ide_helper но ничего нет про стабы моделей, который он генерирует?
3) Зачем ставить левый installer, когда лара создаётся через create-project?

Отвечу так же по-порядку:
1) Под виндой чтоб все «из коробки» работало — прям над моим комментом об этом cjmaxik написал.
2) Про composer.lock уже обсудили чуть выше, а про паблик — не весь паблик в игнор. Там правила, некоторые файлы оставлять.
Вот, прогоняю gulp — он создает в папке `public/build` ресурсы с версией. Загоняем их в репу. На другом компе выгружаем с репы, меняем исходник — gulp — гоним в репу. В результате у нас ненужные файлы копятся, ведь, старые-то не удаляются.
Также у меня в папке public подключен storage — если его не запретить на выгрузку — он все файлы из папки гонит в репу. Это не есть гут.
2.1) Во времена 5.0 читал где-то на эту тему, что не стоит включать их в сборку. Также, во времена уже даже 5.2, при попытке залить пул-реквесты в пакеты на гитхабе, авторы пакетов просят убрать этот файл и перезалить пул-реквест.
4) «Левый» инсталлер, это который на офф сайте написан?)

First, download the Laravel installer using Composer:
composer global require «laravel/installer»


Make sure to place the ~/.composer/vendor/bin directory (or the equivalent directory for your OS) in your $PATH so the laravel executable can be located by your system.

Once installed, the laravel new command will create a fresh Laravel installation in the directory you specify. For instance, laravel new blog will create a directory named blog containing a fresh Laravel installation with all of Laravel's dependencies already installed:

laravel new blog

1) Это аргумент, да, я бы согласился, если бы это требовалось бы реально. Только они никак не относятся к изучению фрейма, как следствие — лишний акцент на технологии.


2) Как раз js\css должен собираться локально и пуллиться в репу сбилженный, т.к. это обязанность фронтэндера, а бекендер вообще ничего не должен знать о том как это всё собирается, ему нужен результат. И… В папке паблик лежит сторадж, что? о_0


2.1) По-этому надо их игнорить все, все 3 файла, а не только 2. Логично? =)


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

1. Это да. Просто упомянул, что есть средство значительно лучше денвера)
2. Я за. Проблема — лишние файлы в репе. Еще подумаю над этим вопросом. По поводу storage в доке написано. В 5.2 версии нужно было симлинк вручную прописывать, а тут команду дали: `php artisan storage:link` — она автоматом так делает. Симлинк `/public/storage` ведет на `/storage/app/public`
2.1. Тоже подумаю)
3. По инсталлеру никто не заставляет. Всего лишь написал что он есть и как сделать, чтобы заработал. Там же и написал:
Для этого у нас есть две команды на выбор:

laravel new blog
и
composer create-project --prefer-dist laravel/laravel blog


Они обе выполняют одно и то же действие, разница лишь… И так видно в чем разница)


Преимущество? С практической точки зрения между обеими командами преимуществ нет, ибо выполняют одно и то же действие одинаково. А с точки зрения времени, первую и писать быстрее, и запоминать легче. Например, `laravel new mysite` я помню наизусть, а `create-...` дальше не помню — надо лезть в офф доку, искать строку, копировать и вставлять в консоль. Лично для меня муторно.
  1. Лол, спасибо, что-то проглядел такое! =)
  2. И как же указать папку и версию фрейма (ну например нужен LTS) для create blog? ;) А если долго запоминать — есть:
    а) IDE с визуальной штукенцией
    б) alias
    в) IDE с автокомплитом
Вряд ли большинство новичков будет принудительно выбирать LTS, учитывая что их, насколько я понял, больше не будет.
Большинство введет одну из двух комманд по ману. Это факт. А кому потребуются параметры — воспользуются командой через композер.
`create-project` качает фрейм средствами композера, а `laravel new` — установщиком Лары, устанавливаемый самым первым по ману:
First, download the Laravel installer using Composer:

composer global require «laravel/installer»
5.3 уже стабилен? На продакшене кто-нибудь использует?
5.3.7 уже версия официальная)
Если про фреймворк.
5.3 это версия ларавел или РНР?
Добавил линк в статью. Пусть будет.
По пункту отправки писем. Очень удобно использовать mailtrap.io.

По окружению: уже или «по взрослому» работать и повторять прод в виртуалке или забить на redis, apache, nginx.
ставим в .env
CACHE_DRIVER=file
SESSION_DRIVER=file
QUEUE_DRIVER=sync

и работаем через встроенный сервер. В итоге нужны только php+node+git. Можно и базу sqlite использовать.
`DB_CONNECTION` — используемый тип драйвера. В случае с PostgreSQL указываем `pgsql`, а в случае с MySQL/MariaDB — `mysql`.


Не совсем верно. Это не тип драйвера это имя подключения по умолчанию из конфига database.connections.
А мне вот недавно встретилась информация, но Ларавель требует каких-то там настроек сервера, которые очень сильно затрудняют его использование на shared-хостинге. Вплоть до полной невозможности. Да?
Я предполагаемый новичок при использовании фреймворков (Реально не было необходимости использования фреймворков любых, хватает своих самописов за пару часов). Сейчас «модно» использовать фреймворки, и при устройстве на работу необходимо знать хотя бы основные моменты их использования.
И мне совершенно не понятно для чего и почему нужно так много операций проводить. Оперсервер ставится просто кнопочками Next и Готово. (предполагаемо) Laravel как и другие фреймворки просто скачиваются/копируются в папку домена, единственно надо знать что и зачем скачивать/копировать. А дальше любимый нотепад и вперед на амбразуры по инструкции аля «Мой первый блог на Laravel».
Вот такая инструкция для меня как новичка бы подошла. А так выходит, что чуть ли не убегать от использования фреймворков с такими хелпами приходится…
Каждому свое. Лично мне на начальных стадиях знакомства, подобная информация помогла и то была только в англоязычном сегменте.
Здесь, как говорится, всем не угодишь. Кому-то поможет, а кому-то нет.
Вы сейчас из какого года нам написали? (Это к >Сейчас «модно» использовать фреймворки)
Сейчас, это значит зашёл на hh и просерфил требования. Я же написал что новичок.
И судя по комментариям к статьям — ваш вопрос также «модный»
В пункте про описание gitignore команды npm. Или у меня в отображении страницы косяк?
Нет, не у тебя.
Вчера текст обновлял и не заметил где накосячил. Сейчас исправлю.
Лучше в config/app.php не указывать провайдеров, которые необходимы только для разработки.

Рекомендуют использовать для этого app/Providers/AppServiceProvider.php.

В методе register:

if ($this->app->environment() == 'local') {
$this->app->register('Laracasts\Generators\GeneratorsServiceProvider');
$this->app->register('GrahamCampbell\Exceptions\ExceptionsServiceProvider::class');
$this->app->register('Barryvdh\Debugbar\ServiceProvider::class');
$this->app->register('Barryvdh\LaravelIdeHelper\IdeHelperServiceProvider::class');
}
Такое неоднозначное чувство, когда решил зайти прочитаь статью для новичков о фреймворке, на котором работаешь уже давно и мало того, что от самой статьи не увидел никакой практической пользы для новичков, так еще и вредных советов наоставляли в ней вагон. Про вредные советы при этом пишут выше, а автор чуть ли не с пеной у рта спорит. Но я зайду с другой стороны — зачем автор написал сие творение? Вроде уже даже документации на русский достаточно много перевели, для самых упертых противников английского языка. Нет — всеравно будем писать статьи с вредными советами. Ждем статью о том как сделать блог на ларавел.
где «Developer» — имя моего компьютера

Может всё таки имя пользователя?
Sign up to leave a comment.

Articles