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