Как стать автором
Обновить

Комментарии 58

Разработчика, который такой хренью от ребят из scotchbox.io пользуется — на работу брать нельзя.

Это уже 3-й уровень деградации.
Почему?
Разработчик должен иметь собственное уникальное, окружение.
Которое он должен уметь конфигурировать.
Это как .vimrc.

Человек, который пользуется этим — начинающий программер, врядли от него будет много пользы. Придется всему учить год.
Вы еще скажите, что приложения на сервера нужно вручную деплоить :)
При чем тут это?

Последний раз напишу:

Каждый девелопер проходит путь от LAMP до собственного уникального и удобного окружения, в котором он самостоятельно размещает проекты, над которыми работает.

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

Не свое оптимальное, а общее, на базе скотчбокс, закатанное в виртуальную машину.

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

А лучше всего, чтобы он имел свой ноутбук с развернутой средой разработки.

О чем тут спорить?
А лучше всего, чтобы он имел свой ноутбук с развернутой средой разработки.

О чем тут спорить?

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

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

Мне кажется можно. Хотя я бы выбрал бы того, который может сам себе мастерскую построить, если бы смог предложить ему достойную ЗП :)
Тогда и я напишу :)

Твое окружение — это твое окружение. Рабочая среда есть другое.
Вот я пришел на большой проект, мне нужно поставить определенную версию java, прописать тыщи переменных в PATH, поставить тулзы для фронт-энда, еще кучу всякой ерунды. Можно конечно сделать мануал и добрые пол-дня несчастный джуниор будет все это устанавливать, и еще может вас дергать при неудачах. А еще очень часто такие штуки забывают апдейтить.
Вагрант и уже готовый образ создадут энв как раз плюнуть.

А редакторы и прочие инструменты для себя вот тут уже простор для фантазии открыт :)
Если вы JAVA программер — значит вы знаете все основные тулзы, которые используются в JAVA мире. Все это уже установлено и настроено на вашем ноутбуке вами. И вы умеете этим пользоваться.

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

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

То, о чем говорится в статье — ерунда. Виртуальная машина с предустановленными апачем и майскл ничего не решит. Кроме того — это преподносится как что-то новое. Пиарят какой-то скотчбокс, в котором зачем-то есть руби и пхп, но нет питона и перл. Почему именно такая конфигурация? В чем проблема сделать такой-же образ самому? Если уж на то пошло — лучше выдавать докер с проектом внутри.
Что вы предлагаете делать если вы пилите два проекта, к примеру? Один как хобби, с другой версией той же джавы, например?
Если есть возможность сэкономить несколько дней и дать возможность коллегам не наступать на одни и те же грабли, то уж лучше сэкономить. Дедлайны не резиновые.
(Даже не глядя внутрь) Если там Убунту — в ней перл уже точно есть. Может, и питон заодно найдётся.
Он там точно есть, если «ребята из скотчбокс» его поставили из репозитория.

Так же я могу набрать «apt-get install apache2» без проблем.

Вопрос был — чем обусловлен такой выбор софта и почему он считается универсальным.
Уметь что-то делать самостоятельно и использовать готовое, не противоположные вещи. Часто ли Вы что-то собираете из сорцов, когда есть бинарники, полностью удовлетворяющие вашим требованиям, но созданные не Вами? Или пишете код для решения популярной задачи, которая до Вас была решена уже тысячу раз? Готовое обычно можно использовать быстро, просто и эффективно, эти сборки от ребят из scotch box не исключение. Не говоря уж про то, что некоторым разработчикам вообще не обязательно знать что, да как там работает.
Преимущества боксов и докеров в том, что окружение максимально приближено к реальным и разработчик не задумывается, ту ли версию ПО он поставил, надо ли обновлять php/mysql или нет.
А еще каждый разработчик должен иметь самописный уникальный фреймворк. Который только он должен уметь конфигурировать.
Каждый должен ездить на собственном велосипеде, собранном из запчастей через слезы и страдания. Человек, который едет на покупном — начинающий велосипедист. Такого придется учить собирать велосипеды год.
Да хватит этого бреда.
Сколько вам лет?
Извините за некропостинг, но вот моё мнение, которое я никак не мог оставить при себе:
1. Обычно, именно из-за «собственного уникального окружения» возникают ситуации вида «а у меня на компе всё работает». Окружение должно быть максимально близким к боевому. Scotchbox это только вариант такого окружения, как и написано в заголовке, «для ленивых». Никто не мешает вам сделать аналогичную сборку самостоятельно.
2. Использование таких готовых окружений позволяет не тратить время на настройку «собственного уникального окружения». Если надо быстро что-то протестировать, то не нужно убивать как минимум час на установку в VM операционной системы и настройку софта.
Это уже 3-й уровень деградации.
А вы когда нибудь пробовали создавать собственные Vagrant боксы? Обратите внимание на жёлтый дисклаймер на этой странице. Реально думаете что те кто не умеют создавать такую же «хрень» на третьем уровне деградации?
Второе ваше предложение не понял.

Какой еще дисклеймер? Advanced topic? И что это должно значить?

Я выразил свою точку зрения, подкрепленную многолетним опытом работы в крупных дев. коллективах.

Это ваше дело, как организовать процесс разработки максимально эффективно.

Хотите — садите всех на скотчбокс.
Несколько консольных команды никакой сложности не представляют, дисклеймер видимо для домохозяек о которых как раз пишет alaska332
У вас большой опыт создания собственных вагрант боксов? Можете поделиться? Я думал что «несколько коснсольных команд» это для того что бы запаковать уже подготовленный образ. В доках описана куча специальных требований к образу, которые должны быть соблюдены. Не думаю что это какая то супер сложная процедура, но на первый взгляд это очень далеко от уровня домохозяек.
Любой опытный линукс пользователь выполнит эти требования.

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

Инженерная документация с дисклеймером «Advanced» — это деградация. Это как «Осторожно, горячий суп», чтоб не убили себя. Таких инженеров надо «мочить в сортирах» (с) Вова П.

Весь этот топик отлично демонстрирует уровень современного массового IT.

10 лет назад были шутки про пхпшников, которые не знают как работает компьютер. Сейчас все стало только хуже.
Одинаковые dev, stage / qa и prod окружения очень важны. Решает проблемы вида «а у меня все работает, can't reproduce», это только то, что лежит на самой поверхности, глубже — более сложные вещи типа минимальных различий версий MySQL. При чем тут умение собрать окружение?
Разработчик должен иметь собственное уникальное, окружение.
Унификация рабочего окружения всех разработчиков в команде одна из основных причин использования Vagrant.
Разработчик — не бухгалтер, зачем унифицировать рабочее место?

Что это даст компании? Повысит уровень креатива?
Зачем разработчику свое собственное, уникальное окружение? И у каждого будет совсем собственное и совсем уникальное.

Унифицируют окружение выполнения вашего продукта, а не все рабочее место.

Vagrant + Scotchbox уницфицируют окружение выполнения, в частности, того что доступно из коробки, версии и настройки Apache, PHP, MySQL, etc. А остальное будет унифицировать после доработки напильником.

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

Не надо отвлекаться на продукты, иначе выходит, что все продукты в мире работают на 3-х технологиях.

В чем смысл этой виртуальной машины с апачем, php и mysql? Все это ставиться одной командой из репозитория.

Где эта самая унификация?

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

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

Надо написать «ребятам из скотчбокс», чтобы поменяли на nginx, а то самому ставить придется, а это уже не комильфо.
Я, например, апачем не пользуюсь уже много лет.

Это из области «держите нас в курсе».

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

Кроме вас, этим могут пользоваться многие другие. Чтобы сделать вариацию на тему nginx вы вольны для своих нужд и нужд своей команды собрать виртуалку с nginx, а не писать ребятам из scotchbox, раз уж вы все это умеете устанавливать из репозитория :)

В топике идет речь о рабочем окружении разработки, это не IDE и не .vimrc, а то, на какой конфигурации запускается проект, это как минимум ясно из контекста топика. Вы же начали придираться к словам.

В чем унификация!? Все разработчики запускают код в идентичных условиях, о чем я писал выше.
Например, в команде 15 разработчиков, наступает момент, когда обновляется mysql + php, плюс еще что-то добавляется (ну, например, понадобился Redis). И вы, вместо того, чтобы обновлять и настраивать софт на 15 компах, выполняя команды по обновлению и установке из репозитория. Можете один раз у себя все это настроить, опубликовать образ виртуалки и сообщить команде мол: «Все обновляем виртуальную машину, там уже все сделано».

Ни кто не утверждает, что skotchbox это единственно верный вариант окружения, вариантов масса, а вы накинулись из-за того, что это не подходит лично вам. Это не продуктивно.

Если skotchbox не для вас, вы можете просто проходить мимо.
К чему это завуалированное хамство?

Вы воспринимаете мое, в общем-то, субъективное мнение относительно подхода к организации процессов, как личное оскорбление? Взбешены? Сжали кулачки?

Для софта лучше, если он будет запускаться под различными окружениями. Больше отловите багов. Но к делу это не относится.

Поставьте еще пару минусов толпой, пусть это вас утешит.

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

Я, думаю, как и многие, нахожу это продуктивным.
Больше отвечать не буду.
Сразу трудно было не ответить?

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

2. Как относятся ваши пространные рассуждения об упаковке проекта в виртуальную машину к теме статьи и проблеме, которая в ней затронута? Зачем вы мне рассказываете о ваших местных проблемах, и как вы с ними боретесь? О боже, как же это удобно, шарить виртуальную машину. Наконец-то найдена панацея. Теперь любой дебил сможет писать код для нашей компании, ведь ему не надо будет ставить редис самому. Подскажу, есть еще более эффективное решение — терминальный сервер. Попробуете?

3. На счет — «держите нас в курсе». Я вам вроде ничего не должен, с какого х… мне держать вас в курсе чего-то? И кого это «вас»? Хотя я тоже очень люблю веселый штампованый юмор.
Батенька, да у вас бомбит!

" он только умнее станет,"
ну и если вместо отдела бухгалтерии он будет финансами заниматься тоже умнее станет и если вместо дизайнера макеты рисовать, дак может этим и заниматься?
Если человек делает JS на проекте, зачем ему базы то ставить и php настривать?
Нельзя не согласиться, унификация необходима если работаешь в команде
А никто не сталкивался с проблемой медленного исполнения кода в вагранте и как с этим боролся? Вроде как проблема возникает из-за прикрепленной папки в виртуальную машину, но вот как победить не могу разобраться
Ну, это известная проблема, в частности, если используется (дефолтный) VirtualBox и его механизм расшаривания папок. VMware работает заметно быстрее, но вообще проблема решается использованием NFS (правда, только если на хост-машине не Windows).
NFS решает проблему только частично. Как вариант держать файловою систему внутри виртуальной машины. toster.ru/q/217009
для Windows есть плагин:

vagrant plugin install vagrant-winnfsd
На мой взгляд решение от puphpet.com более гибкое. В 2015 году перешел именно на связку VBox + puphpet + vagrant с хранением проектов и диска вм в дропбоксе. Удобно, гибко, доступно. Единственная проблема — забываю vagrant suspend и компьютер зависает на выключении. Не получается повесить на shutdown выполнение скрипта
Поддерживаю puphpet.com. Отличная тула и решает все описанные в посте задачи, вероятно даже и быстрее — генератором конфига на их сайте в пару кликов.

А про приостановку вагранта — использую VMWare, никаких проблем с выключением компьютера не замечено.
Скотчбокс хорош для реально быстрого деплоя среды окружения разработки, чтобы быстро начать. Причём не важно на какой ОС разработчик сидит. Это удобно когда нужно сделать что-то быстро, например на хакатоне, или быстро прототипировать.
А вообще, лично для себя, лучше докера пока решений не вижу. Мгновенная работа сервисов, относительно «чистая» основная ОС без лишних пакетов, мгновенная работа приложений (в отличие от более длинных пробросов файлов в виртуалку, и т.д. в вагранте).
Опять же, всё зависит от стэка. Докер позволяет конфигурить вообще как угодно среду исполнения. Хочешь — django, хочешь lamp, хочешь rails, хочешь нода. Еще Ansible и скрипты автоматического деплоя на DO или AWS — так вообще ракета-космос ))
А вот утверждать что скотчбокс это плохо и нубство — это большая глупость. Любая технология хорошо, а если она еще правильно применяется — это еще лучше! Для каждой задачи есть свой набор инструментов, и безусловно здорово, что ребята из скотча придумали такую сборку. Только с обзором этой сборки опоздали немного, это было очень актуально где-то год назад. Сейчас докер )
Именно этот комментарий должен идти к этой статье первым, а не странные обсуждения «зачем мне ехать на лифте, если я умею подниматься по лестнице» :)
Сейчас докер, да.
на практике связка vagrant+docker еще сильнее выходит.
Почему?
потому что мультиплатформенно.
Под винду, для быстрого старта denwer удобен
это в прошлом веке уже.
О, напомнили.
Регистрация требуется в связи с будущим выходом Денвера-4.

На моей памяти лет 5 уже висит дисклеймер. Ну и пусть дальше висит :)
Отличная работа, чего тут разводить споры — автоматизация она всегда нужна. Респект автору, и побольше здоровья и сил, чтобы продолжать.
Теперь при переходе на habrahabr.ru, будет грузится сайт с нашего хоста на виртуалке.

Не будет. Изначально ip другой и будет работать только — 192.168.33.10
Ну и проблемка еще с SSH может возникнуть…

Как раз решил поставить попробовать и схватил эти грабли.
А, прошу прощения, такой IP установлен, если устанавливать по инструкции Scotch.io напрямую. В топике все верно.

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

Публикации

Изменить настройки темы

Истории