anatoly60: да мильен их. Делаем билд (deb пакет, zip/tar.gz архив и т.д.) и какая-нибудь система для деплоя (плейбук для ansible, capistrano и подобные... в зависимости от того на чем вы собственно пишите бэкэнд).
у меня два вопроса:
1) для флайплана нужно ставить что-то на удаленном сервере? (как минимум я вижу что требуются некоторые настройки на сервере что бы работал sudo)
2) А вы смотрели на ansible? как по мне намного проще и удобнее вашего варианта.
sim3x: ух... проблема в отсутствии времени... Была у меня мысль сделать для примера что-то типа trello с плюшками (логирование времени, разделение тасков на компоненты, фильтры и поиск) но как-то все заглохло. Хотя фильтрики может выдеру от-туда на неделе ибо может пригодиться в админках. По поводу карзины товаров - тут вообще никак. Было аж две статьи на хабре (так себе к слову статьи) где описывались эти штуки, если подкрепить комментариями можно сделать нормально.
sim3x: в смысле? Ну.... фильтр он и в африке фильтр. Просто форма, датабиндинг все такое, мэпится все на объект-критерию, которая уже в каком-то формате передается в query на сервак, тот его как-то разруливает (есть даже RFC регламентирующая формат для фильтров фасеточного поиска) и отдает JSON коллекцию.... выводим....
То есть тут мы имеем довольно тривиальную форму (или не тривиальную в зависимости от сложности фильтров), но сами понимаете никакого отношения к магазину задача как такавая не имеет. Далее мы имеем объект со всеми параметрами поиска. Далее нам нужен реквест трансформер этого объекта в запрос на сервак. Ну и все.
С карзиной все намного проще. Есть сервис карзины, кладем туда товары.... там запоминаются айдишки и количество в локал сторадж какой или сешен сорадж на ваш вкус иии все. Единственное чего не могу сказать - вопрос с изменениями цены. Скажем добавили вы в карзину товар, а через час цена изменилась (то есть товар все еще в карзине но заказ еще не оформлен). Как быть в таком случае? То есть если бизнес логика магазина отрицает изменение стоимости товара если товар был добавлен в карзину - то у нас проблемка ибо секьюрно это сделать без добавления специфичной логики на бэкэнде не представляется возможным. С другой стороны это настолько специфичный кейс.... обычно только после оформления заказа такое работает.
Ой да ладно... Если все эти сложности по хранению состояний и т.д. перенести с бэкэнда на фронт (в том числе и админку делать на angular) то на сервере остается красивая и легкая REST API, которую удобно суппортить и все такое.
А в магазинах важен не бэкэнд/фронтэнд а просто важно как все сделано. Что бы ориентировано было на покупателей, что бы покупатель увидел интересующий его товар и в конечном счете купил. А за счет чего это сделано - дело третье.
brud: я еще не пришел к четкой структуре которая бы мне нравилась, но ассетик под эту структуру адаптировать у меня не вышло никак. Сейчас думаю над каким-то своим вариантов. В данный момент проблема только в инджекте скриптов в шаблон (инлайнинг маленьких скриптов которые нужны для инициализации, менеджеры модулей например и просто еще какие-нибудь веселые штуки).
Станислав Найденый: пороги какие-то... кто их придумал... суть в том что заказов для PHP сильно больше, если можете на RoR бложик поднять или там магазинчик или еще чего - то в бой. Но заказов меньше. Как вариант - навязывать свой стэк технллогий заказчику. Но для этого надо аргументировать.
С заказами же до 6 человеко месяцев царит PHP. Ruby ебинственный кто в эту нишу может успешно влесть. Python как по мне уже для более крупных проектов. А вот RoR придумали исключительно для быстрой разработки. Java/C# - большие проекты. Есть шанс что .NET с MVC Next выстрелит и тогда можно будет жить но пока php или ruby.
Станислав Найденый: что плохого в PHP? У него 80% всего бэкэнда. А если брать небольшие проекты то и того больше. Его проблема в том что пишут на нем любой и каждый, чем портит статистику.
des1roer: не "засорять" а использовать возможности выбранного инструмента. На самом деле тут можно много спорить о преимуществах и недостатках. Тут вам решать на самом деле.
Ну я вот тоже типа-программист... но почему-то не под виндой (хотя люблю винду), и ничего не знаю лучше чем консольный клиент для postgresql.
des1roer: а еще можно агрегирование повесить на базу - сделать там процедурки, вьюшки и т.д. Тогда все и работать будет быстро, и логика в PHP упростится.
Вы представляете себе как много вариантов сделать то что вы хотите? Умножить это еще на количество вариантов что и как вам нужно агрегировать и получим число стремящееся к бесконечности.
des1roer: >>админить базу делов то не много
Вот да, чест слово... поувольнять всех этих инженеров по базам данных, получают дохера за не пыльную работу.
>>ems manager лучше всех.
Вы может еще и под виндой?
>> агрегирование ... на пхп\js
Пара тройка SQL запросов, json_encode и скормить результат какой-нибудь либе для чартов. Ну да, это сложно.
