По поводу reflection. Что имел в виду? Собирать информацию о файлах (драйверах) в директории = количество. Качество = описание этих модулей путем чтения doc-блоков.
Не совсем понял вопроса. Как одно противоречит другому? В форме (регистрации или входа) обычно имеются ссылки или иконки соц. сетей и подписи "Войти через...". Ссылка должна быть отображена. После входа=регистрации через соц. сети ее не нужно показывать, пока пользователь авторизован.
Спасибо вам. Дали почву для размышлений и направление для действий. На данный момент не приступил к технической реализации. Пытаюсь понять, что нужно переработать в разработке, чтобы внедрить то, о чем говорили. Поэтому, не смотря на то, что отметил решением, если вы не против, естественно, хотел бы продолжить общение, пусть и в рамках данного ресурса. Т.е. вопросы еще будут.
Вынужден не согласиться. На англ. очень много информации, но если проблемы с англ, то https://gitter.im/LaravelRUS/chat - Этого за глаза, чтобы решить любую проблему. Все разработчики русскоязычные, всегда кто-то в онлайне. И религия тут совсем ни при чем.
Ага, спасибо, перевариваю. Пока следующий вопрос. Информация в каждом из блоков (назовем их так) должна быть "живой" или это анализ информации с определенным временным интервалом, ее сохранение и использование? Elasticsearch (ES) производительное хранилище, но злоупотреблять не хотелось бы.
При этом нужна не рыбка, а удочка. Не нужны готовые решения. Более того, товары могут быть совсем нетипичные, что сводит на нет возможность использования каких-либо справочников.
"с этим товаром также покупают", "самое просматриваемое в категории", "новинки категории", "самое покупаемое категории" - более или менее понятно. Аналитика. Использую Elasticseach. На его базе это достаточно просто реализовать штатными средствами, без заморочек с логикой.
"вы уже смотрели" - тоже, что и в предыдущем случае, но проще.
"с этим товаром также смотрят" - любопытно.
"аксессуары к ", "сопутствующие", "похожие" - эти стоят особняком. Логика работы тут примерно одинаковая - связи. Эти интересуют более всего.
@Илья, второй пункт - в десяточку. Это главная причина, по которой хотел оставить цифровую часть. Можно очень легко хранить справочник всех имен как категорий, так и товаров и делать автоматический редирект. Еще раз - в десяточку ) Тогда - мой первоначальный вариант остается: site.com/catalog/2435/nazvanie-categorii, site.com/product/1224352/nazvanie-tovara. А для SEO плюсом будет то, что URL логичны и коротки. Плюс - в URL название товара полностью дублирует текущее название товара на русском языке, но в транслитерации. Я правильно понимаю?
Я на эту тему и сомневался - я про три клика. Слишком длинный адрес до добра не доведет? Проще сделать как описал дальше, т.к. уровень вложенности может быть разным. Оптимальным будет вариант (у некоторых крупных магазинов, кстати, так же, они в топе): site.com/catalog/nazvanie-categorii (любого уровня), а для товара site.com/product/nazvanie-tovara ?
vsnovikov: по поводу настороженного отношения к российским курсам. Не совсем понимаю вашей настороженности. Информация о веб-программировании - это набор технологий, изобретенных не в России и не россиянами. Информация сама по себе международная. Если говорить о манере преподнесения этой информации, то есть люди, умеющие преподнести эту информацию и хорошо и плохо. И эти люди существуют как в наших широтах, так и за их рубежом. Нужно только найти свое. Сам, кстати, люблю некоторых зарубежных авторов. Не потому, что они зарубежные, а потому, что меня не устраивает все остальное. К чему это я все? Не совсем корректно использование словосочетания "международные курсы".
По поводу рецептов. Разные сайты, найденные по ключевым словам: "php tutorials, js tutorials и пр."
Вот несколько из собственного набора:
По поводу Zoho Builder. Имеет смысл, если вас это устраивает. Всегда есть исходные требования. Если это решение подходит под ваши требования, то имеет смысл завязываться. Но надо понимать, что этот инструмент предлагает определенный набор инструментов, специально созданных для вас. Т.е. ограниченный круг заранее придуманных и реализованных инструментов. Если вас устраивают эти "рамки", то еще раз - завязывайтесь. Если нужно больше, то нет. Все предельно просто. Если вы это понимаете и просто хотите, чтобы вас склонили к тому или иному варианту, т.к. вы сомневаетесь, то тут тоже надо понимать, что у каждого свои предпочтения. Относительно объективное мнение на этот счет я написал выше. И да, билдеры сейчас имеются в достаточном количестве, чтобы можно было выбирать. Мне попадалось около 5-ти разных (достаточно хороших) точно.
По поводу статей - на за что. ) Первоисточник указан там же, в статьях. По поводу книг. Вы спрашивали про базы данных. Очень хорошая книга на эту тему, если не лучшая - это MySQL. Оптимизация производительности. Это если вести речь про РСУБД MYSQL. Кстати, авторы там зарубежные.
Под прием заявок конечно подойдет тот же самый набор инструментов. Проще будет сказать под что этот набор не подойдет, т.к. реализовать можно на базе этого набора очень многое.
Уточню. Графика критична только с точки зрения плавной работы графического интерфейса Yosemite, ее интерфейса. Возможно, что буду работать с видео. Но тут, насколько я понял, нагрузка ляжет на процессор...
Текущий сервер вполне может быть передаточным звеном. Вот тут один вопрос возникает... А получится эту загрузку транзакционно сделать, совместно с другими данными формы?
