-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
VCS: внедрение в работу
- Автор темы scorpion-ds
- Дата начала
fixxxer, это относится ко всему - git, framework , phpunit, seleniun, ci. Если не молиться и не читать кучу статей, а взять мануал и сделать, то потратив 1 день освоишь технологию на 80% и дальше будешь экономить кучу времени. Но сейчас все растут на стетеках и после сотой статье по технологии начинают к ней относиться как к rocket science.
Я внутри компании сделал воркхоп по ангулряру и ларавелу в связке. Взял слайды по каждой технологии и дополнил прилагой сделанной на коленке за час. Через три дня одна команда переписала свой проект на ангуляр и у них залетал интерфейс, избавились от кучи говна и багов в js и магии jquery.
Я внутри компании сделал воркхоп по ангулряру и ларавелу в связке. Взял слайды по каждой технологии и дополнил прилагой сделанной на коленке за час. Через три дня одна команда переписала свой проект на ангуляр и у них залетал интерфейс, избавились от кучи говна и багов в js и магии jquery.
scorpion-ds
Новичок
scorpion-ds, вёрстку делать в отдельных ветках, поступила задача на вёрстку,завели отдельную ветку, верстальщик поправил нужные страницы если шаблоны не умеет, то потом программист в той же ветке делает это. Проверили, всё ок, мержат в основную ветку. На нрмальных проектах вёрстка - это как правило измениния в уже готовой, так что она не должна проходить отдельно, это не удобно и делается тройная работа.
Отдельно дизайн, так как там тяжёлые psd, то лучше делать в отдельном репозитории.
Отдельно дизайн, так как там тяжёлые psd, то лучше делать в отдельном репозитории.
Absinthe
жожо
Выгоняем этого оболтуса и нанимаем нормального. Хотя бы за 50тр/месяц по московским ценам.
Бонусом получаем увеличение количества сделанной работы за константное количество денег.
Absinthe
жожо
Я тут подумал, в какой именно момент разработчики начинают считать, что верстальщик должен знать шаблонизаторы.
В тот, когда проект нужно поддерживать. Включая верстку: где-то внести изменеия. Т.е. в любом проекте, который как-то дожил хотя бы до релиза (ведь нельзя все с первого раза сразу сделать правильно).
Значит ли это, что у тех, кто не считает, что верстальщик должен знать шаблонизаторы, нет законченных проектов?
В тот, когда проект нужно поддерживать. Включая верстку: где-то внести изменеия. Т.е. в любом проекте, который как-то дожил хотя бы до релиза (ведь нельзя все с первого раза сразу сделать правильно).
Значит ли это, что у тех, кто не считает, что верстальщик должен знать шаблонизаторы, нет законченных проектов?
Систему контроля версий нужно использовать если у вас не используется общих сетевых ресурсов. Потому что зачастую, работают на общем хосте, через сетку (NFS, Samba) и отвечать только за свои изменения становится нереально сложно (нужно приучить себя к частым коммитам). Если у каждого своя локальная копия продукта, то тогда нужна система контроля версий. Поскольку задачи тривиальные, то git скорее не подойдет по причине того, что в git принято выливать финальный результат работы, лучше svn и частые коммиты, что бы все разработчики (два, три) могли видеть то, что было сделано через ценрализованный сервер (логи, дифи) и по необходимости ре-интегрировали изменения. Например, один ковыряет корзину заказов, второй делает каталог, еще и верстальщик исправил баги. Одно цепляется за другое, но поскольку задачи хоть и разные, но имеют пересекающиеся участки кода, то нужен ценрализованный доступ к информации о прогрессе работ, внесенном вкладе и т.п.. Поэтому, даже пока что-то не готово например в визуализации того же каталога, и нужны common (общие) методы - то логичнее их будет ре-интегрировать (частично слить) из соседней ветке второго (третьего) разработчика, если они им были выполнены.
Ни каких шаблонизаторов типа Smarty, Twig и тп., только PHP Native. Задача разработчика (PHP) внести в базу знаний того, что ассигновано в native шаблоне и подкрепить это все всевозможными примерами. Шаблонизаторы убоги и фактически повторяют PHP .. Логика в том же smarty просто пиз..ц. Один "math" чего стоит, foreach'и. Конструкции типа {$blabla|htmlspecialchars} если и можно будет внести, то уже хорошо. Работать с многомерными массивами сложно, с объектами и тем более. Ни какого автокомплита не доступно! Гораздо приятнее работать с
PHP:
<?php
/* @var $this base_native */
/* @var $title string */
/* @var $list multitype:base_user_list */
?>
<h1><?php print $title?><h2>
<ul>
<?php foreach ($list as $_li):?>
<li><?php print $_li->getName();?></li>
<?php endforeach;?>
</ul>
Последнее редактирование:
Что это за сферическая легкость мерджей?)))
Устарело, безнадежно устарело.
Так и работают в небольших студиях. Верстальщики себе хосты не поднимают. Кодеры тоже.
А зачем что-то поднимать? Ничто не мешает разворачивать виртуалки из шаблона на девел-сервере.
Нет централизованного сервера (кому-то + / кому-то - ).
Это если вы работаете надо одним двумя проектами и группой. Для "завода" не вариант.
Почему нет? Куда все пушат - там и централизованный сервер. Формально его нет, фактически - есть.