alexaandrovp

Человек задал достаточно конкретный вопрос, а вы демагогию развели (кроме ув. OnYourLips - он дал ценный ресурс).
У меня сейчас такая же ситуация, хочу обновить знания в современном мире PHP и JS, подбираю как правильно выстроить курс обучения. Согласен пройти уже снова всё с нуля, но "правильно".
Итак, поделюсь с вами находками:

• Книга "PHP Pandas" научит снова с азов (PHP7 тоже уделено внимание). Книга бесплатная.
  
• Дальше рекомендую пробежаться по разделу PHP на замечательном сайте W3Schools. И не только по разделу PHP.
  
• Jump Start PHP Environment - отличная новая книга, которая научит вас некоторым современным штукам при работе с PHP проектами: быстрым развертыванием виртуальных машин через Vagrant, использованию git, работе с Composer и затронет вопросы деплоя. Книга небольшая и максимально полезная.
  
• Раз уж упомянули выше ресурс PHP The Right Way, стоит продолжить эту тему, так как автор этого ресурса выпустил целую книгу Modern PHP.
  
• Awesome PHP - классный список на github с нужными библиотеками, хорошими ресурсами, книгами и т.д. по PHP.
  

А дальше нужно садиться за изучение фреймворка. У нас по-прежнему очень популярен Yii, хотя у меня душа лежит изучить скорее Symfony. На западе сейчас очень популярен Laravel.

Если вам нужны будут книги выше в эл.виде, можете связаться со мной или погуглить.

Внутри Docker только Linux, и, экспериментально, FreeBSD. Запускается нативно под Linux и, экспериментально, под FreeBSD. Под MacOSX, Windows - через виртуальную машину.

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

Это почти виртуальная машина. Почти, да не совсем.

Есть такое понятие "ад зависимостей". Любое ПО устанавливаемое на компьютер, тянет за собой зависимости (конфигурационные файлы, статические файлы называемые обычно asset, вспомогательные утилиты/сервисы, библиотеки и пр.). Ряд из этих библиотек/утилит/сервисов несовместим друг с другом. А с учетом того, что каждая из этих библиотек/утилит/сервисов имеет и свои зависимости - ситуация еще хуже.

Например, мы используем Yandex.Cocaine, которая нормально компилируется только на Ubuntu 14.04 (и, вроде, на Debian 7). Но не под CentOS 6, 7, Debian 8, FreeBSD 9, 10, Ubuntu 15, 16 и пр. - скомпилировать его невозможно. Запускаем в этих операционных системах в Докере.

С другой стороны, и одновременно с этим, вам необходимо установить другое, более современное ПО. И одновременно более старое. Причем речь даже не идет об серьезно отличающихся версиях Linux. Например, одно ПО требует не менее Ubuntu 14.10, а другое не более Linux 14.04.

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

Таким образом, мы имеем бинарный файл запускаемый как бы в своей операционной системе.

Вы можете сказать - ба, да это же давно известная виртуальная машина. Но нет, это не так. Это так называемые контейнера. Никакой виртуальной машиной там и не пахнет. За исключением Windows и MacOSX, где работа без виртуальном машины пока экспериментально возможно только, а нормой в этих ОС является использование Докера внутри полноценной виртуальной машины.

Но виртуальные машины с Докером используются только для разработки. Для запуска в production виртуальные машины с Докер не используются.

Докер использует контейнеры операционной системы. LXC в Linux, Jails в FreeBSD. Контейнер - это область операционной системы, изолированная от основной части операционной системы. В контейнере свое дерево каталогов (включая системные /dev, /bin, /sbin и пр.), свои сетевые порты и пр. и пр.

Но при этом не используется полная виртуализация. Что существенно экономит ресурсы. Запустить 100 полноценных виртуальных машин вряд ли получится даже на мощном сервере. А вот запустить 100 контейнеров Docker даже на слабом домашнем компьютере - возможно.

Правда использование не полной виртуализации ограничивает использование операционных систем внутри контейнеров. Как правило, это специально подготовленные версии Linux или FreeBSD. Именно специально подготовленные. Windows - в принципе в контейнере запустить невозможно.

Контейнеры существовали и до Docker. Докер, строго говоря, это всего лишь очень удобный набор инструментов, собранных воедино, для управления контейнерной виртуализацией. Но очень удобный.

Зачем это используется?

Ребята из всяческих Dropbox, Facebook и и пр. гигантах, запускающие по 1 млн. различных программ в своих сервисах, столкнулись, что невозможно везде гарантировать идентичные настройки операционной системы. А это критично.

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

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

Более того - изначально разработчик программного обеспечения тестирует программу в контейнере Докер, с определенными настроками. И в этом же (или с такими же настройками) контейнере Докера программа уезжает на сервер.

Это позволяет гарантировать гораздо большую идентичность среды разработки и среды исполнения.

До этого люди мучались, придумывали хитрые инсталяторы...

Потом плюнули на попытки упорядочить окружение в ОС - и сейчас концепция такова - устанавливать программы на сервера вместе со своими индивидуально настроенными под них операционными системами - то есть внутри контейнеров. 1 контейнер = 1 настройка ОС = 1 программа внутри.

Другими словами:

• Докер-контейнер нужно использовать для отладки.
  
• Тот же Докер-контейнер нужно использовать и на сервере.
  

Это позволяет не трудиться с настройками "под сервер" локально на машине разработчика. Это позволяет разрабатывать на машине разработчика совершенно разные программы одновременно, которые требует несовместимых настроек операционной системы. Это позволяет давать гораздо больше гарантий, что программа на сервере будет вести себя также как и на машине разработчика. Это позволяет разрабатывать под Windows/MacOSX с удобным "прозрачным" тестированием под Linux.

Докер применим к созданию/настройке только серверного программного обеспечения под Linux (экспериментально под FreeBSD). Не для смартфонов. А если десктопов - то только программное обеспечение без GUI.

Посколько Докер позволил одним махом упростить работу разработчикам и админам и повысить качество результата - сейчас бум на Докер. Придумано огромная гора инструментов для управления развертыванием приложений созданных с Докером. Если раньше чтобы запустить 10 000 программ на 1000 серверах нужно было как минимум 3 высококвалифицированнейших девопса, которые писали кучу описаний как это сделать на Puppet, Salt, Chef, Ansible, да и то не было гарантий, это все тестилось месяцами. То сейчас с Докер даже один квалифицированных девопс может рулить миллионами программ на десятках тысяч серверов. С куда как большей гарантией, что все это заведется нормально.

UPD:

Может сложиться ложное впечатление, что разработчик готовит контейнеры в Докер, а потом передает их админу.
Правильная методология все же другая:

Разработчик отдает весь свой результат в систему CI (обычно через git)
CI на каждый новый коммит делает с помощью Docker образ для тестирования.
Если тесты проходят успешно, то этот же самый Docker образ, отправляется на развертывание в production.
Или, чуть иначе в компилируемых системах, где исходники не нужны в production: в Docker производится развертывание среды для компиляции, а для тестирования разворачивается второй образ с уже откомпилированным добром, который уже отправляется в production.

То есть при правильной огранизации дела разработчик не может/не должен влиять на то, какой будет образ.
А вот в тестовой среде (запускаемом на сервер, недоступном разработчику в больших командах) и в production как раз используется один и тот же образ.

Основная идея - что тестировали, ровно то и запускаем на боевом сервере. Один-в-один, включая те же самые файлы (не такие же, а именно те же самые).

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

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 спасение и решение всех проблем, но я как сисадмин от этого всего не в восторге.

Добрый день.
Читать документацию, смотреть проекты на github, пытаться написать своё решение для какой-либо задачи....
Вот несколько ссылок, которые Вам помогут:
1) rmcreative.ru (блог одного из разработчиков yii2)
2) https://github.com/samdark/yii2-cookbook (рецепты от того же разработчика)
3) www.elisdn.ru/blog/tag/Yii2 (один из блогов, где можно учиться работать с yii2)
4) https://github.com/yiisoft/yii2/tree/master/docs/g... (документация на русском от разработчиков yii2)

По своему опыту выделил для себя следующие правила.
Физика:
1. Питание. Обрати внимание на сахар и быстрые/медленные углеводы. Например, если утром поесть овсяную кашу то энергии хватит на 4-5 часов, если бутерброды, - часа на два. Так по крайне мере у меня.
2. Физические нагрузки, спорт отнимает много времени, хотя очень эффективен. Самый простой способ - побольше ходить, если пользуешься общ. транспортом, то выходить на несколько остановок раньше. Еще можно отжиматься, где-то читал что сто отжиманий в день - тонус для всех мышц тела.
3. Сон. Как и другие рекомендую 7-8 часов, однако нужно обратить внимание на матрас, температуру и влажность в комнате - это намного улучшит качество отдыха.
4. Жидкости. Я пью обычную воду, стараюсь выпивать 2 литра на работе (у меня есть вот такая фляга )
5. Свежий воздух в офисе, яркость света. Стараться работать согласно нормам описаным в охране труда, т.е. должно быть много света, должен быть приток свежего воздуха.
6. Эргономика стола. Обязательно нормальный стул, стол, монитор, клавиатура. Многие пренебрегают этими вопросами, а потом в 30 лет грыжи в позвоночнике, туннельный синдром, линзы/очки и половая дисфункция. (Я понимаю что в 18 лет это звучит как что-то далекое и не про тебя, однако если ты планируешь связать свою жизнь с разработкой, нужно думать о туловище, а не только о мозге)

Психика:
1. Будут дни когда работа не прет, абсолютно. Отпустить и забыть, но не увлекаться.
2. Дисциплина. Так как мозг считай мышца, нужно постоянно тренировать ее; - писать код. В конце концов мозг привыкнет к нагрузке и сможет решать любые задачи и быстро, но будут дни как в первом пункте.
3. Супер важные ежедневные задачи. Для меня это учеба и английский. Я этим занимаюсь не зависимо от дня недели, праздников, событий. Т.е. даже если я узнаю что через три дня конец света, все равно буду оставшиеся дни делать то что и делал раньше. Можно смеяться и крутить пальцем у виска, но нужно объяснить мозгу, что не может быть никаких проволочек, никаких отмазок. Иными словами “сдохни, но сделай”. Этот навык мне позволяет в случае аврала или какой-то мегалажи не паниковать и планомерно решать задачи. (Лучше начинать потихоньку иначе пункт первый на несколько лет)

Через пол года у твоего мозга закончится адаптационный период и в этот момент начинай думать о своем туловище, оно не будет тебя отвлекать от решения любых умственных задач.
Книги:
https://pragprog.com/book/jkthp/the-healthy-programmer
www.ozon.ru/context/detail/id/4320305

В свое время похожее меня терзало, но остался с руби и доволен как слон. Несколько помог вот этот доклад, который увидел как-то тут же, на тостере.
https://youtu.be/xPFRUM_oDKA

А если от себя - руби, а в частности рельсы не умрут. Особенно с теми обновлениями, что есть в 5 версии.

Вот список моих подписок на youtube )) везде есть что-то полезное.
Блоги
uWebDesign
Ilya Kantor
Master-CSS
Magisters
WebDesign Master
webtheory
Уроки веб-разработки
WPRUSe
Artem Demo
AutoLineX
CMTV [IT науки]
Codecourse
Hexlet
ITVDN
knowcity
LevelUpTuts
loftblog
Ocode
Petr Bafloker
ProDevZone
Radik Fattakhov
Russian WordPress Developer
Victor Zinchenko
WebMarik
Создание сайтов. Maxtop.org

Конференции
404fest
DEVCLUB.EU
FrontendDevConf
GeeksLab
ITmozg.ru
OdessaJS Conference
Веб-стандарты
Фронтенд

Разное
GetDevNET
Образовательный IT-портал GeekBrains
WEB iT [xaver.ru]
Роман Левищенко
SiteHere

Вот забавный парень, правда говорит на английском (но довольно простым языком):
https://www.youtube.com/channel/UCO1cgjhGzsSYb1rsB...

Может еще вот, что понравится:
Конференции:
* MoscowJS
* Веб-стандарты
* DEVCLUB.EU
* Айти-Событие
* IT ШКОЛА SAMSUNG
* Яндекс: Разработка
* Яндекс: Фронтенд
* Яндекс: Управление проектами
* Яндекс: Системное администрирование
* Яндекс: Компьютерные науки
* Академия Яндекса
* NextCastle Party

Подкасты:
* Подкаст "Как Делают Игры"

Блоггеры:
* Дмитрий Бачило

Долго потому, что композер проверяет все зависимости пакетов, а у пакетов есть ещё много зависимостей, как правило.

Если нужно обновить одну либу используем:
composer update package/name

Ещё можно добавлять параметр "--prefer-dist", тогда composer будет стараться ставить либу из архива, а не клонировать репозиторий.

Использовать рубишную версию стоит только если она тебе точно нужна

bover конечно круто использовать, но нафиг он нужен если все есть в npm?
Да и прибирать за ним нужно

'use strict';
/*
npm install --save-dev  \
  gulp  \
  node-sass \
  gulp-sass \
  compass-mixins  \
  bootstrap-sass  \
  gulp-autoprefixer \
  gulp-minify-css \
  gulp-sourcemaps
*/

// load plugins
var gulp = require('gulp'),
  sass = require('gulp-sass'),
  autoprefixer = require('gulp-autoprefixer'),
  minify_css = require('gulp-minify-css'),
  sourcemaps = require('gulp-sourcemaps'),
  path = require('path');

gulp.task('sass', function () {
  gulp.src("paths/to/sass/files/**/*.sass")
    .pipe(sourcemaps.init())
    .pipe(
      sass({
        includePaths: [],
        imagePath: "path/to/images"
      })
      .on('error', sass.logError))

    // https://github.com/ai/browserslist
    .pipe(autoprefixer("last 2 version", "> 1%", "Explorer >= 8", {
      cascade: true
    }))

    .pipe(minify_css({compatibility: 'ie8'}))
    .pipe(sourcemaps.write('./'))
    .pipe(gulp.dest("paths/to/css_dir"));
});


//watch
gulp.task('live', function () {
  //watch .sass files
  gulp.watch("paths/to/sass/files/**/*.sass", ['sass']);
});

gulp.task('default', ['live']);

Кусок моего галпфайла. Что-то снабдил комментами.

var connect      = require('browser-sync'); // livereload
var sass         = require('gulp-sass'); // Кому что, я использую SCSS
var csscomb      = require('gulp-csscomb'); // Обязательно!
var cssmin       = require('gulp-cssmin');
var imageop      = require('gulp-image-optimization'); // Лучшая альтернатива gulp-imagemin
var concat       = require('gulp-concat');
var uglify       = require('gulp-uglify');
var plumber      = require('gulp-plumber'); // Не позволяет плагину умереть молча
var autoprefixer = require('gulp-autoprefixer');
var ngrok        = require('ngrok'); // Пробрасываем локальному серверу путь наружу для для заказчика
var spritesmith  = require('gulp.spritesmith'); // Спрайты
var notify       = require('gulp-notify'); // Уведомления
var merge        = require('merge-stream'); // Деление таска на разные потоки

Конечно, есть много полезного и кроме этого. Но сам верстаю в WebStorm, в котором огромное количество плюшек реализованы куда удобней, чем в галп-плагинах.