как реализовать функционал, я более-менее представляю, задаю вопросы по той части, с которой не сталкивался, например назначение и привязка доменов, архитектура с одной общей БД на весь сервис, или отдельными БД под каждого пользователя (склоняюсь что к разным, так как нагрузку в будущем надо будет разруливать, и распределять, рано или поздно это будет жопа).
Иван Шумов, понимаю о чем Вы говорите, я понимаю что сам не спроектирую, но в целом хочу иметь предмет для обсужедния, понимание как это работает хотя бы поблочно. Что делается на уровне сервера, как программно будет организован конструктор, как хранится данные (в разных или все в одной бд), как файловая система будет устроена. Я сам пишу сложные ТЗ, но связанные с технической архитектурой 1С Битркс, но тут более низкоуровневое программрование, точнее системы. Мне нужно представлять в общем.
Программист есть, архитектора нет, но возможно привлечем, или с программистом обсудим архитектуру.
Я для этого пост и создал, что бы понимать, где с какой стороны есть ограничения, но прихожу к выводу, что в целом ограничений технических нет, поэтому архитектуру можно заложить любую.
И у каждого варианта будут свои особенности в скорости разработки, методах поддержки, масштабирования, и самое главное - дальнейшего развития. С учетом масштабирования, и развития, в обсоенности. Потому что в самом простом случае, мы все можем повесить на одну базу, на одну файловую систему, но рано или поздно это все начнет трещать по шву от нагрузки. Либо от безопасности)))
Знаю конечно, в тильде пользователь сам прописывает ААА записи у регистратора.
Я уже прихожу к тому, что на уровне нашего сервера можно сделать как угодно. Всмысле есть техническая возможность хоть свой NS поднять, хоть свой DNS и разруливать только AAA записи, а наш сервак будет тыкать нужный домен ( на уровне нашего DNS) в нужную директорию.
Это один способ. Разделить функции конструктора, и пользовательских данных.
Проблема с архитектурой в том, что я никогда не сталкивался с серверными настройками и DNS зоной (только как пользователь), а как это делается автоматически?
Я думаю, что у готовых серверов (LAMP, Nginx) есть API, туда подается команда, типа такой домен отнести к такой категории. И через api делается проверка AAA записей, но не уверен что именно так.
А исполняемый код проверяет ответы и выдает пользователю в личном кабинете результат (домен настроен, не настроен, прилинкован).
Нужно узнать у тех, кто занимается серверами. Вот и спрашиваю) Так это или не так.
Да, верно. Тогда возьмется фрагмент 1440 от изображения.
Либо верстальщик может сделать так, что изображение 1920 впишется в 1400, но останется вопрос, хватит ли высоты изображения. Так редко делают, но технически можно.
Соглашусь, нужно идти в художественную школу, а потом садиться за адоб иллюстратор.
Форма, тени, объем, перспектива, рефлексы. Все это должно изучаться сначала в художке.
mrbykovoleg, как раз и зайдут, как база. Котлер - это вообще, в целом библия маркетолога с 80-ых годов, по ней преподают в вузах до сих пор, ирекомендует Тиньков как книгу, которую должен прочитать каждый предприниматель, в ней заложен фундамент того, как пользователь выбирает и покупает, и его истинные мотивы, добавочная стоимость, брендинг, репутация, и все разложено по полкам.
Вторая книга, конвершен оптимизейшен, это уже более адаптированная версия, прикладая, о том как маркетинг внедрен в сайты, КАК ИМЕННО пользователь принимает решение, как сделать продающий сайт (любой, а не только лендинг).
В первой книге вы сформируете базу, во второй, помете как это все применять конкретно к сайтам. Книги мелкие, каждую за выхи, а то и за вечер можно прочитать. Но для усвоения, рекомендую их сделать настольными.
Есть две ключевые ошибки
- пытаться оформлять хреновое предложение - бесполезно, можно получить просто красивую картинку, которая будет радовать творческое начало собственника и дизайнера
- пытаться самому придумать оформление - есть большой секрет всех крутых дизайнеров, и самый главный из них - никто ничего сам не придумывает. Берутся две-три чужие идеи, плюс пара своих.
