@zds "Меня смущает, что это все вытесняет профессии дизайнера/программиста. "
Это иллюзия. Конструкторы и CMS есть давно, и у них есть своя ниша.
А програмирование, и тем более качественный уникальный дизайн будут нужны всегда.
Программирование там, где нужно что-то работающее быстро, масштабируемое, нестандартное.
Дизайн тем, у кого что-то большее бложика или домашней страички.
Я как раз дал вопрос на ваши ответы, где в моих словах что-то из вашего вопроса?
Если хотите больше конкретики - пожалуйста.
Вы спрашивали "куда рости" и "как больше зарабатывать". Если вы считаете, что как дизайнер вы уже хороши, то надо работать над своим именем. Это даст возможность стабильнее получать вкусные заказы, и поднимать при этом цену за заказ.
Инструменты - публикации, участие в публичных событиях, конкурсах, возможно создание какого-нить курса, видео уроков и.т.п. Всё, что позволит узнать о вас как о профессионале в своей области.
Второе - изучать юзабилити, чтобы делать дизайны не только красивые, но и удобные и отвечающие задаче. Инструменты: книги, статьи по данной тематике, и.т.п.
@fornit1917 Вам надо определить, что тормозит, для начала. И там будет видно, что делать. Хранение кеша в memcached нужно прежде всего тогда, когда у вас работает несколько бекэндов и нужен один общий кеш. В обычной ситуации файловый кеш, который по умолчанию используется, вполне справляется со своими задачами.
@Masterme Да, это можно сделать либо написав свой модуль, либо, что в данной ситуации правильнее, использовав готовый функционал Drupal. Естественно руками добавлять поле в таблицу, ни в коем случае не надо - делая так, вы делаете не поддрживаемый проект. А в drupal сделано много как раз для того, чтобы такими отвратительными вещами не заниматься.
Видимо, вы просто не пробовали и не понимаете.
@inkvizitor68sl Там, уж простите, и диски совсем не те же. Внимательно перечитайте ответ.
Тут не в интерфейсе дело, а в куда более древних и медленных дисках.
Ну и "медленее шаред хостинга" часто от неправильной настройки.
Каждому инструменту своё место. Такой подход уместен, в разработке приложения с нуля, и я им пользуюсь при разработке проектов на yii, например. И в этом случае миграции нужны, вполне согласен.
Но зачем вам менять структуру БД Drupal?
Если вы разрабатываете свой модуль, со своими таблицами, вы можете воспользоваться таким подходом, в принципе, написать скрипт из нескольких строк кода, для применения/отмены изменений в БД не сложно. Но это делается отдельным проектом, а потом модуль уже устанавливается, разворачивается готовая схема данных, и возможно, начальные данные.
И, кстати, у модулей Drupal есть install, update, uninstall коллбеки, которые автоматически срабатывают при установке, обновлении, удалении соответствующего модуля...
Т.е. на уровне необходимом для такой работы миграции всё же поддерживаются. А тащить лишние инструменты в ядро не стоит.
Кстати, посмотрите на schema. (https://drupal.org/project/schema)
На SATA3, те же диски, не будут работать заметно быстрее , за исключением некоторых шустрых SSD, которые в SATA2 действительно упираются.
Скорость доступа к памяти в общем-то тоже не так уж тут заметно будет влиять.
А вот "числодробилка" в современных процессорах, конечно, заметно круче. И если узкое место будет в вычислительных нагрузках, тогда да - заметно уделает.
@issssrt Посыл верный, и тут писалось всё это уже. Вот только modx, отнюдь не чудо и не супер, это странное поделие дизайнера является CMS второго эшелона, и то с натяжкой...
А фреймворк xPDO, который вы называете богатым API, не сильно функционален и крайне неудобен.
Если у вас в багаже только джумла, простите, но вы просто "не в теме", и не видели ничего приличного. Вам обязательно надо посмотреть другие варианты - есть куда более сложные и многофункциональные инструменты.
И сразу отпадёт желание, делать странное и писать велосипеды, которые ведь потом и поддерживать придётся, а это тоже будет нетривиально...
@Masterme А зачем CMS общего назначения миграции? Они нужны там, где вы меняете структуру БД, и вам нужна версионность этой структуры. А тут, структура базы данных создаётся не вами, и вы принимаете её как данность.
Зато в drupal есть более актуальные для разработки сайта на CMS инструменты - devel, помогающий отладке, features, помогающий вторично использовать готовые части функционала, и кстати, с поддержкой версионности и.т.п. Т.е. довольно развитый инструмент поддержки разработки.
Ну есть куда более одной CMS, где админка и темизируется и переделывается не хуже, чем морда. Я вот в Drupal этим активно пользуюсь, например.
Было же выше сказано - найти инструмент под свои нужды. Делать свой почти всегда мало продуктивно - исключением тут может быть создание каких-нибудь не стандартных, но однотипных сайтов разве что. Тогда да, можно сделать инструмент под данную задачу заточенный на котором она будет рализовываться быстро, работать шустро и.т.п.
А писать CMS общего назначения с нуля дело неблагодарное. Ну и вспоминается lurkmore.to/%D0%A4%D0%B0%D1%82%D0%B0%D0%BB%D1%8C%D...
@Masterme В том смысле, что вы сможете заработать больше, чем затратили на её разработку - да, когда-нибудь сможете.
В том смысле, что за какое-то конечное время заработаете больше с ней, чем без неё настолько, чтобы окупить разработку - очень, очень спорно. Вполне вероятна даже обратная ситуация. Я бы сказал, что она намного более вероятна, особенно, если делать не однотипные сайты.
@VovanZ Вообще такие есть, но в основном те, кто дошёл до осознания того, что использовать фреймворк разумнее, уже довольно профессиональны и откровенно говнокода не производят. Ну и наличествующая архитектура и договорённости помогают, конечно.
@Quber Написав свою, вы быстро поймёте, что столкнулись с теми же проблемами. А то и бОльшими, т.к. очень мало разработчиков может хорошо продумать заранее архитектуру приложения. И велосипедов с квадратными колёсами море.
А под большинство распространённых CMS уже есть готовые решения, которые позволяют их расширять в нужном направлении. И то, что вы быстрее пишете расширения для своей CMS, будет уже не так полезно и выгодно на практике.
