У нас есть 12 стандартов, давайте сделаем 1 универсальный — компания А
У нас есть 13 стандартов, давайте сделаем 1 универсальный — компания B
У нас есть 14 стандартов, давайте сделаем 1 универсальный — Lofer
Идеально, если веб-дизайнер и верстальщик — одно лицо (ещё лучше, когда он же — ещё и программист, но это, скорее, редкость, чем правило)
Как по мне то это плохая идея. Обычно это приводит к тому, что верстальщик начинает править дизайн, если что-то не выходит с версткой. В целом считаю, что нужно разделять максимум сферу обязанностей.
p.s Я вообще не представляю верстальщика который без IPS матрицы работает… Тоже самое, что детским совочком капать траншеи…
Выбор инструментов, дело личное. Думаю, настанет время, когда Вы почувствуете, что час пробил. В моём случае это, когда захотелось запустить одну прогу, в которой все включено.
В данном случае, я и пытаюсь понять, что Вас так возмутило.
Я думал данный сервис, нужен для того, чтобы узнать, что-то новое. В моем случае, процесс выстроен так. Если Вы можете дать, конкретную ссылку или описать тут, как делать «правильно» буду только рад, повторюсь, сам в этом заинтересован.
, компиляция стилей средствами IDE, взята из документации
Вы правы, можно добавить task(sass), task(watch), как на писал KaLGaN, но:
Нужно запускать доп. процесс который будет проверять изменение файла, в то время как IDE можем само это делать, средствами своего наблюдателя(watcher)
В случае с большим кол-вом проектов, у каждого проекта должен быть свой файл, настроенный, и для каждого нужно запускать отдельный процесс.
Так же могут возникнуть проблемы с проектом, где будет модульная верстка(т.е в каждом компоненте хранится свой sass + css), по сути мне нужно будет забивать пути для хранения всех компонентов(хотя я тут могу ошибаться, как-то не доводилось таким заниматься)
Только недавно вычищал из проекта древний Compass, куда такие вот php-разработчики засунули.
Не совсем понял, почему эти файлы ушли на сервер, по идеи они должны быть в игноре. В моей случае на сервер улетают только package.json, gulpfile.js, файлы проекта(html, php, sass, css). Вся магия связанная с nodejs и gulp делаются исключительно на локальной машине.
Если Вы считаете, что правильней, как-то по другому организовать, я радостью изучу этот момент, т.к. очень в этом заинтересован.
Спасибо, учту это при обновлении статьи. Сейчас обновить не могу, т.к. это может ввести в заблуждение пользователей WebStorm, т.к. части компонентов в пустой коробке просто нет.
По ряду причин:
1. Кол-во установленных инструментов из коробки больше чем WebStorm, а чтобы их поставить/настроить это время и тихий ужас со стороны верстальщиков.
2. Ввиду тесной работы с Php-разработчиками, удобно когда единое IDE.
3. Частенько приходиться править PHP код(шаблоны которые содержат код), а с PhpStorm это проще.
Для меня этих пунктов хватило, чтобы отдать предпочтение Phpstorm.
У нас есть 13 стандартов, давайте сделаем 1 универсальный — компания B
У нас есть 14 стандартов, давайте сделаем 1 универсальный — Lofer
Или речь идет о компиляции css и конечном каталоге куда класть .sass -> .css?
Как по мне то это плохая идея. Обычно это приводит к тому, что верстальщик начинает править дизайн, если что-то не выходит с версткой. В целом считаю, что нужно разделять максимум сферу обязанностей.
p.s Я вообще не представляю верстальщика который без IPS матрицы работает… Тоже самое, что детским совочком капать траншеи…
Я думал данный сервис, нужен для того, чтобы узнать, что-то новое. В моем случае, процесс выстроен так. Если Вы можете дать, конкретную ссылку или описать тут, как делать «правильно» буду только рад, повторюсь, сам в этом заинтересован.
Вы правы, можно добавить task(sass), task(watch), как на писал KaLGaN, но:
Не совсем понял, почему эти файлы ушли на сервер, по идеи они должны быть в игноре. В моей случае на сервер улетают только package.json, gulpfile.js, файлы проекта(html, php, sass, css). Вся магия связанная с nodejs и gulp делаются исключительно на локальной машине.
Если Вы считаете, что правильней, как-то по другому организовать, я радостью изучу этот момент, т.к. очень в этом заинтересован.
1. Кол-во установленных инструментов из коробки больше чем WebStorm, а чтобы их поставить/настроить это время и тихий ужас со стороны верстальщиков.
2. Ввиду тесной работы с Php-разработчиками, удобно когда единое IDE.
3. Частенько приходиться править PHP код(шаблоны которые содержат код), а с PhpStorm это проще.
Для меня этих пунктов хватило, чтобы отдать предпочтение Phpstorm.