Тайгер

Странные конечно ответы отмечены решениями, меня это несколько удивляет.
Немного расскажу автору вопроса про вагрант и докер, в чем разница.
Вагрант - это лишь обертка над virtualbox для создания заранее сконфигурированной машины в виртуалбоксе. Польза от него есть, но только для разработчиков. На продакшн сервер Вы не сможете развернуть то же окружение при помощи вагранта.

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

Докер, в отличии от вагранта, позволит Вам иметь идентичные окружения и на дев-сервере, и на продакшн, и на тестовом, и везде, где только можно. Этим он выгодно отличается от вагранта.
Вагрант в связи с вышеупомянутым недостатком и ориентированность только на дев-окружение, тихонько отмирает.

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

На счёт того, как конкретно развернуть на докере ламп или что-то подобное, сперва прочтите Getting started на оф. сайте докера, затем гляньте на докхабе образы для веба, там их несколько и каждый описывает инетерсные подходы.

Удачи, надеюсь мой комментарий был Вам полезен.

Представьте что нет никакой ложки докера.

1) Есть одна физическая машина. Вы устанвливаете софт, разные приложухи, базы, web сервера, заходят тестовые юзеры, что-то запускают. Первая проблема - вы не понимаете кому что надо, кто владелец файлов, приложух, зачем висят демоны и кто за это ответственнен. Как выход, вы решаете это разделить на виртуалки.

2) У вас есть физическая машина + на ней виртуалки. Вы выделяете под каждую задачу свою виртуалку, там сидят отдельные пользователи, вы навели какой то порядок. Появляется задача - пользователи хотят php 6, а его нет, хотят python3, а его нет, хотят Mongo, а она старой версии. Вы обновляете репозитарии, качаете новые пакеты, ставите, часть пользователей довольны, часть нет - им нужна старая версия какая была. Упс!

3) Одна физическая машина + еще больше виртуальных машин. Вы разделили всех пользователей так, чтобы никто не дрался за версии софта, если нужен php6 - иди на эту машину, нужен php5 - вот на эту. Все счастливы, но появляются разработчики, которые говорят буквально так - "а у меня на рабочей машине все работает, я перенес все как было на виртуалку, а у меня появляется ошибка missing library libXXX.so.X". И вы понимаете что вам остается только создать полную копию машины разработчика, чтобы софт поехал на этой виртуалке без ошибок... И тут появляется Docker! :)

4) Docker решает именно эту проблему. Вам не нужно заботится о софте который установлен на сервере/виртуалке. Вы просто берете и переносите софт со всеми "кишками" на другой сервер и он просто работает. Работает за счет того, что все "кишки" это слои файловой системы нанизанные как бисер друг на друга. Дополнительно решается проблема свободного места, т.к слои многократно переиспользуются контейнерами, если вам нужен php + одна библиотека, а другому php + другая библиотека, вы используете (грубо говоря) слой php, а для дополнительной библиотеки делаете отдельный слой, одновременно другой человек делает над php другой слой и вы не деретесь между собой и не видите чужих библиотек. Это грубо и скорее всего ради одной библиотеки никто новый слой не делает, делают слой пожирнее.

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

Laravel одним архивом cabinet.laravel.com/latest.zip

или по отдельности:
Larael https://github.com/laravel/laravel/releases
а vendor к нему так https://composer.borreli.com/

Используй join
https://developer.mozilla.org/ru/docs/Web/JavaScri...

return arg.join('');

Да как сказать Yii - это ящик с гаечными ключами. Можно ли по ящику понять - зачем ключи? Ну можно, если долго ключи использовать как пишут разработчики - то и поймешь со временем, но есть риск провалится в "делаю как сказали, почему - не знаю".

Коли про ООП вопрос: разработчикам нужно было писать меньше повторяющегося кода, чтобы не менять одно и то же по 10 раз. Давай по-порядку.

Представь ассоциативный массив (ключ-значение).
Теперь представь функцию, любую, пусть будет abs() - число по модулю.
А теперь забрось эту функцию в свой массив на место какого-нибудь ключа, то есть у тебя как будто получится $array["abs"], где лежит сама функция.

В чем отличие функции от других данных? Данные ты можешь записать, а можешь считать. А функцию ты еще и выполнить можешь. Таким образом когда ты ее вкинул в массив, у тебя лежит не функция там, а ее заготовка, под выполнение. И ты можешь ее вызвать но уже не как abs(), а как $arr['abs']() - что будет выглядеть одинаково (под капотом все сложнее, но пока забей, оно тебе не надо)

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

Таким образом ООП это когда ты сначала описываешь внешний вид массива, а потом создаешь вот эти "улучшенные массивы" по описанному виду. Но это только малая часть всего движа.

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

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

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

Об ООП стоит думать как средство уменьшения числа кода. Если у тебя к примеру два поставщика и два разных файла выгрузки, а действия в них одни и те же - можно прибегнуть к ООП, сделав тип "Поставщик" и описав в нем - что он умеет делать над своими "экземплярами-объектами-улучшенными_массивами" и тд.

Прежде чем считать, что ты не сможешь без ООП тебе нужно понять, что любая вещь МОЖЕТ быть сделана без ООП. Просто количество путаницы если ты бросишь этот код и вернешься к нему через месяц и уже не помнишь что где и когда - будет больше. Классы создают некую описательную структуру того, что происходит и оттого часто в крупных проектах писать на ООП длиннее дольше и тяжелее, чем без ООП.

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

ООП тебе понадобится, когда у тебя возникнет очень отчетливое чувство что "блин, вот язык этот какое дерьмо, мне так задрало вот эту штуку каждый раз заново писать, почему они сразу этого не сделали?" - вот тогда тебе надо заняться ООП, и тогда его будет легко понять.

Я не про то, что типа "еще рано" и тд. Я про то, что есть куча вещей в которое можно отдать время, более интересных и полезных, чем погружаться с башкой в эту муть, которая на деле кроме чувства мнимого превосходства тебе ничего не даст. Просто делай как удобно, и только когда решишь своим массивам задавать поведение - типа "при присвоении ключа в поле `name` автоматически создать поле `code` с таким-то содержимым" - вот тогда реально можешь повкуривать что тут еще можно мутить.

1) Учеба в вузе никак не мешает учебе самостоятельно, вы же не в мединституте учитесь? 60% времени вы свободны. Если тратить не на пивас и погамать, то можно обучиться строить космические корабли и бороздить просторы вселенной
2) Это хорошо, а как у вас с иностранными? Если хорошо - то 100% стоит получить корку и думать в сторону европы, а еще лучше - сразу попробовать обучаться в Германии например, там образование бесплатное.
3) Я в школе тоже не видел смысла учить русский, английский(который давался мне с аццким трудом), и прочие истории с географиями, однако сейчас понимаю что даже те зародыши английского что тогда в меня впихнули помогли мне быстро вникнуть в технический английский, и быстро вырасти в знаниях когда объем данных на английском вырос просто взрывообразно. И да, в институте в вас пихают много чего не особо полезного, тут вопрос в том что во первых - просто способность запоминать растет на объеме, и второе - способность понимать логику разных предметов(скажем так - не тупить при нестандартных ситуациях) тоже на одном конкретном предмете не научишься.
4) Заочное вариант если вы реально сами поднимете скилл на уровень "меня хотят за серьезные деньги", иначе лучше добить очку и потом идти в конторы джуном с последующим стандартным ростом скилов.
5) Зачем было выбирать слабый вуз за больше чем штуку евро в год? Понимаю что возможно это не только ваш выбор но и "указания сверху", но раз вошли в танец - пляшите, терять время на перевод + опционально переезд скорее всего невыгодно ни по времени, ни финансово.
6) Очень плохо - это что? Не дали профильных знаний? Не обеспечили направлением на работу? Не учились и получили диплом с хреновым баллом? Раскрою тайну - 90% вузов не дают актуальных знаний, это обусловлено кучей вполне понятных факторов, начиная от персонала, который должен быть компетентен в современных технологиях, и заканчивая сроком утверждения и обновления учебных программ, учитывая нехилую бюрократию и зависимость от министерств/ведомств етц.
7) Всегда есть варианты проще и дешевле, и вообще можно устроиться без образования, но как верно подметил Stalker_RED, с корочкой просто больше выбор.

Соберите в cordova - работы на пол часа с условием установки android sdk и настройки переменных окружения, посмотрите как выглядит. Собрал приложение доставки на cordova + vue + yandex checkout sdk (написал свой простой плагин для нативных библиотек android и ios) - все отлично работает. Ибо нет большого смысла поддерживать 3 приложения (desktop, mobile, app), учитывая то, что два последних - это одно и тоже.
Да и для прототипа - самое-то, приложение раньше увидит свет, а когда появится необходимость в том, что нельзя реализовать на cordova - перепишете нативно.