Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 230
Другое: MediaWiki.
Использую MODX.
P.S. Его стоило бы добавить в основной список, т.к. система довольно популярная и имеет достаточно большое сообщество
P.S. Его стоило бы добавить в основной список, т.к. система довольно популярная и имеет достаточно большое сообщество
Это та, у которой шаблоны в БД хранятся? Популярна?
Да популярна, вон на cmsmagazine на 5-ом месте. И шаблоны уже давно можно хранить не в базе, а в файлах.
Это полноценный и отличный фреймворк. А кому что-то не нравится с шаблонами, запросто свое прикручивает без хаков ядра. Как я сделал php-шаблоны на замену стандартным и использую Smarty. И каталоги/магазины делаю по 10-30 тысяч товаров запросто и крутится это не на VDS.
Но судя по карме, диалог бессмысленный…
Но судя по карме, диалог бессмысленный…
Фреймворк там xPDO, и он откровенно ужасен.
Сложно xPDO назвать фреймворком. Это ORM/ORB. Хотя в силу того, что MODX Revolution неотъемлемо основан на xPDO, то наверно с натяжкой можно сказать так.
А вот ужасен или нет… Лично мне он очень нравится. Конечно в наше время есть более прогрессивные вещи, но он мне все равно нравится. А еще ждем выхода новой версии xPDO, полностью переработанной, с автолоэдорами, поддержкой последних стандартов и т.п.
А вот ужасен или нет… Лично мне он очень нравится. Конечно в наше время есть более прогрессивные вещи, но он мне все равно нравится. А еще ждем выхода новой версии xPDO, полностью переработанной, с автолоэдорами, поддержкой последних стандартов и т.п.
Но судя по карме, диалог бессмысленный…
На свои посты ниже посмотрите.
Равно как и на оценки к ним.
Ну и — мерять собеседника по карме — оно не в пользу вашего ума говорит.
На свои посты ниже посмотрите.
Равно как и на оценки к ним.
Ну и — мерять собеседника по карме — оно не в пользу вашего ума говорит.
Вы немного не в теме :-)
Для расширения кругозора сделали тестовый сайт на MODX, упорно продираясь через все сложности.
Несмотря на пиар и красивости «из коробки», MODX — это монстр, достойный сравнения с Битриксом.
Выяснилось, что с ним совершенно невыносимо совместно работать, используя систему контроля версий, т.к. система вынуждает работать через UI и постоянно требует наличие зашитых абсолютных путей в куче конфигов.
Также, нечто, сделанное локально, переносится на продакшн с бубном и плясками. Чего стоит процедура с заменой абсолютных путей в нагенерированных файлах после ручной зачистки кеша через админку.
Вывод — для фреймворка подобное недопустимо. Для CMS — возможно, сгодится.
Несмотря на пиар и красивости «из коробки», MODX — это монстр, достойный сравнения с Битриксом.
Выяснилось, что с ним совершенно невыносимо совместно работать, используя систему контроля версий, т.к. система вынуждает работать через UI и постоянно требует наличие зашитых абсолютных путей в куче конфигов.
Также, нечто, сделанное локально, переносится на продакшн с бубном и плясками. Чего стоит процедура с заменой абсолютных путей в нагенерированных файлах после ручной зачистки кеша через админку.
Вывод — для фреймворка подобное недопустимо. Для CMS — возможно, сгодится.
Могу очень серьезно в этим поспорить с вами.
В первую очередь: вы совершенно не знаете MODX. Сразу уточню: я не говорю сейчас что плохо, а что хорошо. Я просто говорю о том, что вы вообще не знаете MODX-а.
1. Про статические элементы писали выше и не раз. И на гите полно исходников пакетов и прочего.
2. Посмотрите этот топик: modxclub.ru/blog/vehicles/80.html
Хотя мой модуль modxSDK еще очень сырой, но я уже несколько проектов написал с его помощью прям в админке, полностью отказавшись от NetBeens. И мы работаем над проектами совместно.
А на счет гита — я вообще считаю для себя гит вчерашним веком, так как при сведении нескольких веток от разных разработчиков часто есть вероятность конфликтов. Считаю, все должны работать на одном проекта одновременно. Кстати, это та парадигма, которой придерживаются cloud9. Более подробно свои мысли изложил здесь.
По поводу путей в конфиге: много какие движки используют абсолютные пути в конфиге, в этом нет ничего плохого, на то он и конфиг. Но никто вам не запрещает там написать относительный путь, это ваше дело. А в самом движке и в компонентах нигде не пишут абсолютных путей, если руки где надо. Но то, что у вас сложности с переносом, опять-таки — это ваше неумение, а не минус движка. И к вашему сведению, есть система Vapor, которая позволяет делать снимки MODX-сайтов, как полностью, так и частично. И это снимок не несет ядра вообще. Ядро, конфиги, папка админки и т.п. — это все отдельно. В снимке только пользовательская часть. И этот снимок легко можно закинуть на другой сайт, или использовать на modxcloud.com
Более подробно об этом здесь.
К слову, у меня несколько своих готовых сборок, и на каждом новом сайте на старте проекта я только экономлю несколько часов.
Система пакетов — вообще отдельная песня. И можно запросто для себя поднять собственный репозиторий пакетов.
Так что не стоит в таком духе говорить о каких-то минусах. Это не минусы, а ваше незнание системы.
Но можете еще в свое оправдание показать самый крупный проект, который вы сделали и которым гордитесь, и сказать на чем сделали. Посмотрим ваш уровень. По вашим топикам я вижу специальность переводчика, а не программиста. Может не туда сунулись критиковать?
В первую очередь: вы совершенно не знаете MODX. Сразу уточню: я не говорю сейчас что плохо, а что хорошо. Я просто говорю о том, что вы вообще не знаете MODX-а.
Выяснилось, что с ним совершенно невыносимо совместно работать, используя систему контроля версий, т.к. система вынуждает работать через UI и постоянно требует наличие зашитых абсолютных путей в куче конфигов.
1. Про статические элементы писали выше и не раз. И на гите полно исходников пакетов и прочего.
2. Посмотрите этот топик: modxclub.ru/blog/vehicles/80.html
Хотя мой модуль modxSDK еще очень сырой, но я уже несколько проектов написал с его помощью прям в админке, полностью отказавшись от NetBeens. И мы работаем над проектами совместно.
А на счет гита — я вообще считаю для себя гит вчерашним веком, так как при сведении нескольких веток от разных разработчиков часто есть вероятность конфликтов. Считаю, все должны работать на одном проекта одновременно. Кстати, это та парадигма, которой придерживаются cloud9. Более подробно свои мысли изложил здесь.
По поводу путей в конфиге: много какие движки используют абсолютные пути в конфиге, в этом нет ничего плохого, на то он и конфиг. Но никто вам не запрещает там написать относительный путь, это ваше дело. А в самом движке и в компонентах нигде не пишут абсолютных путей, если руки где надо. Но то, что у вас сложности с переносом, опять-таки — это ваше неумение, а не минус движка. И к вашему сведению, есть система Vapor, которая позволяет делать снимки MODX-сайтов, как полностью, так и частично. И это снимок не несет ядра вообще. Ядро, конфиги, папка админки и т.п. — это все отдельно. В снимке только пользовательская часть. И этот снимок легко можно закинуть на другой сайт, или использовать на modxcloud.com
Более подробно об этом здесь.
К слову, у меня несколько своих готовых сборок, и на каждом новом сайте на старте проекта я только экономлю несколько часов.
Система пакетов — вообще отдельная песня. И можно запросто для себя поднять собственный репозиторий пакетов.
Так что не стоит в таком духе говорить о каких-то минусах. Это не минусы, а ваше незнание системы.
Но можете еще в свое оправдание показать самый крупный проект, который вы сделали и которым гордитесь, и сказать на чем сделали. Посмотрим ваш уровень. По вашим топикам я вижу специальность переводчика, а не программиста. Может не туда сунулись критиковать?
А на счет гита — я вообще считаю для себя гит вчерашним веком
Очень оригинально.
Продолжайте боянить и сливать карму, придурки. Благо нажать кнопочку Вниз, или залить картинку на сайт, это пока еще для вас посильная задача. Ничего, чем больше таких дебилов как вы, тем больше у меня нормальных заказов, так как заказчику нужен нормальный кодинг/продукт, а не вот эти картинки и неосмысленные комментарии. И искренне смеюсь над вами :-)
Продолжайте боянить и сливать карму, придурки. Благо нажать кнопочку Вниз, или залить картинку на сайт, это пока еще для вас посильная задача. Ничего, чем больше таких дебилов как вы, тем больше у меня нормальных заказов, так как заказчику нужен нормальный кодинг/продукт, а не вот эти картинки и неосмысленные комментарии. И искренне смеюсь над вами :-)
заказчику нужен нормальный кодинг/продукт
> код в базе данных
> нет системы контроля версий
> абсолютные пути
> все правки через браузер
Прошу вас, перестаньте, у меня картинки заканчиваются.
Слушай, тебя в детстве грудью кормили или как? Что тормозить то?
> код в базе данных
Здесь кучу раз говорили: давно есть статические элементы.
> нет системы контроля версий
Очень даже есть, и не только гит можно использовать и т.п. Есть еще и собственный класс сравнения файлов. Конечно это не полноценный механизм, но все-таки свою задачу выполняет.
> абсолютные пути
И все-таки тебя в детстве не кормили грудью…
Еще раз: абсолютные пути только в конфигах, и то там их легко можно перебить на относительные пути. Если у тебя правка пары файлов вызывает сложности, я уже говорил: помочь тут нечем.
Но чтобы ты знал: дела с файловой системой в MODX обстоят никак не хуже, чем в других системах. Более того, по сравнению со многими еще и лучше. В MODX давным давно были введены «Источники файлов». Это отдельные объекты, где можно указать как абсолютные пути, так и относительные, и прочие фишки всякие. А главное — типы источников. Из коробки идет два типа: файловая система, и AmasonS3. Умельцы без проблем и Dropbox и прочее прикручивали. В итоге с удаленной файловой системой можно работать как с локальной, и использовать для нужд сайта. Ну ка, на каком известном тебе движке такое есть?
А вот пространства имен компонентов. Может там ты где видишь абсолютные пути?
> все правки через браузер
1. Если ты хочешь работать не через браузер, а через IDE, но у тебя не получается, то это ты дебил, а не система плохая. Это все равно как пенять на самолет, что это херовая штука, только потому, что ты не умеешь на нем летать.
В общем, «нефиг на зеркало пенять, коли рожа кривая». И залей уже еще одну картинку, подтверди в третий раз свой дебилизм.
> код в базе данных
Здесь кучу раз говорили: давно есть статические элементы.
Картинка для дебилов
> нет системы контроля версий
Очень даже есть, и не только гит можно использовать и т.п. Есть еще и собственный класс сравнения файлов. Конечно это не полноценный механизм, но все-таки свою задачу выполняет.
> абсолютные пути
И все-таки тебя в детстве не кормили грудью…
Еще раз: абсолютные пути только в конфигах, и то там их легко можно перебить на относительные пути. Если у тебя правка пары файлов вызывает сложности, я уже говорил: помочь тут нечем.
Но чтобы ты знал: дела с файловой системой в MODX обстоят никак не хуже, чем в других системах. Более того, по сравнению со многими еще и лучше. В MODX давным давно были введены «Источники файлов». Это отдельные объекты, где можно указать как абсолютные пути, так и относительные, и прочие фишки всякие. А главное — типы источников. Из коробки идет два типа: файловая система, и AmasonS3. Умельцы без проблем и Dropbox и прочее прикручивали. В итоге с удаленной файловой системой можно работать как с локальной, и использовать для нужд сайта. Ну ка, на каком известном тебе движке такое есть?
Ну ка, ткни пальцем, придурок, где там видно абсолютные пути?
А вот пространства имен компонентов. Может там ты где видишь абсолютные пути?
Скрытый текст
> все правки через браузер
1. Если ты хочешь работать не через браузер, а через IDE, но у тебя не получается, то это ты дебил, а не система плохая. Это все равно как пенять на самолет, что это херовая штука, только потому, что ты не умеешь на нем летать.
Скрытый текст
В общем, «нефиг на зеркало пенять, коли рожа кривая». И залей уже еще одну картинку, подтверди в третий раз свой дебилизм.
Скажите, а вот на вашей картинке для дебилов вот этот код, который в секции Код шаблона (html), ну где еще не HTML написан, а PHP с подключением внешнего файла, вот он где хранится?
Напомню вам, также, что на хабре нет места оскорблениям, держите себя в руках или уймите баттхерт.
Напомню вам, также, что на хабре нет места оскорблениям, держите себя в руках или уймите баттхерт.
Код хранится в файле, где и положено. И могу вам гарантировать, что этот файл именно инклюдится средствами php, а не из БД берется.
Думаете, я это заслужил, заливая веселые картинки? Нет. И, к слову, MODX — это не единственная платформа, которую я знаю.
А чего вы добились? Я вот как-то ничего такого не заметил. Вы только картинки умеете заливать и типа ржать. Но это в моих глазах и есть признак дебилизма. И я продолжу это утверждать. И можете продолжать прекрываться правилами, и быть может даже слезно попросить чтобы меня заблокировали (и вполне даже могут заблочить), да только ума это вам все равно не добавит. Так что довольствуйтесь тем, что имеете.
protected function _process($properties = null, $content = null) {
if(!$this->isStatic()){return;}
if(!$controller = $this->getSourceFile()){return ;}
$modx = & $this->xpdo;
$this->getProperties($properties);
$resource = & $this->xpdo->resource;
$this->_output = require_once $controller;
$this->_processed = true;
return ;
}
Напомню вам, также, что на хабре нет места оскорблениям, держите себя в руках или уймите баттхерт.Если бы вы читали больше книжек, то знали бы, что оскорблять людей можно не только словами типа «дебил», а всякими типа колкими картинками и т.п. Поясню: вы пока человек, способный писать комменты типа «Мне нравится», «Мне не нравится», «Не понимаю, объясните» и т.п., и вы мне тут картинки суете ржачные, оценивая мои комменты. Вы уверены, что имеете достаточно компетенций, чтобы оценивать? Я один из 8-ми MODX Ambassador в рунете, общаюсь напрямую с разрабами MODX-а, обо мне упоминают и в официальных релизах, и я один из 9-ти официальных разработчиков MODX Revolution.
Думаете, я это заслужил, заливая веселые картинки? Нет. И, к слову, MODX — это не единственная платформа, которую я знаю.
А чего вы добились? Я вот как-то ничего такого не заметил. Вы только картинки умеете заливать и типа ржать. Но это в моих глазах и есть признак дебилизма. И я продолжу это утверждать. И можете продолжать прекрываться правилами, и быть может даже слезно попросить чтобы меня заблокировали (и вполне даже могут заблочить), да только ума это вам все равно не добавит. Так что довольствуйтесь тем, что имеете.
Я один из 8-ми MODX Ambassador в рунете, общаюсь напрямую с разрабами MODX-а, обо мне упоминают и в официальных релизах, и я один из 9-ти официальных разработчиков MODX Revolution.
Спасибо, вы как амбасадор отбили всё желание даже пробовать. Good for you!
Я амбассадор, а не агитатор. Пробовать или нет — это ваше дело. Просто если захотите попробовать, куда с вопросами пойдете?
И не скрою, лично я далеко не всех хочу видеть в сообществе. Простые нажиматели кнопочек меня вообще не интересуют.
И не скрою, лично я далеко не всех хочу видеть в сообществе. Простые нажиматели кнопочек меня вообще не интересуют.
Не судите о самой системе по одному человеку. Он вполне может ошибаться. ;-)
По поводу абсолютных путей — не надо выдвать то что давно устаялось за какую-то супер-фичу. Ввели и хорошо.
Не хочу подливать масла в огонь, но статические элементы в MODX и медиа-ресурсы приводят только к тормозам. Вот тут адекватное исследование с тестами.
Да, я помню про то исследование. Только сразу уточни, что это касается некешируемых MODX-тегов. То есть, если это кешируемый тег, то проблема вообще минимальна. Плюс к этому в phpTemplates+modxSmarty это вообще не играет роли, так как там если и встречаются MODX-теги, то их минимум, и на производительности это не сказывается.
Не понял, то есть, если 10-15 человек будет работать одновременно с каким-то классом, дописывать его из этого самого браузерного IDE ModX, то конфликтов сто процентов не будет? Вы, как мне кажете, пытаетесь доказать несостоятельность того, что сделано, чтобы помогать и упрощать работу Вам же.
Cloud9 придерживается или предлагает использовать и покупать? Это разные вещи, не думаю, что их сервис разрабатывался в Web IDE, конечно, в некоторых ситуациях это может быть удобно, но не значит, что это всегда подходит.
Cloud9 придерживается или предлагает использовать и покупать? Это разные вещи, не думаю, что их сервис разрабатывался в Web IDE, конечно, в некоторых ситуациях это может быть удобно, но не значит, что это всегда подходит.
дописывать его из этого самого браузерного IDE ModX, то конфликтов сто процентов не будет?
Нет, безусловно этого нельзя исключать. Но этого нельзя утверждать и при разработке на IDE+git и т.п. Здесь на этот момент надо просто под другим углом смотреть. Вот давайте простую ситуацию рассмотрим: Два разработчика сделали клоны проекта и сидят себе работают. Безусловно, пока они работают сами по себе, у них все ОК. Но как только эти проекты сводятся в единую версию, кто вам может гарантировать, что конфликтов не будет? Никто. Только на практике уже будет видно есть конфликты или нет. И, кстати, в данном случае совершенно нет гарантии в том, что эти два программиста не работали над одним и тем же классом, и один не сломал что-то важное для другого.
В случае же, если эти два программиста работают одновременно над одним и тем же проектом, то как только один зацепил и поломал что-то, то увидит это не только он, но и другой участник проекта. В идеале суть сводится к тому, сколько бы людей не работало над проектом, проект всегда един, и всегда в актуальном состоянии, и каждый ощущает на себе изменения проекта.
В общем, ни один, ни другой механизм конечно же не исключает конфликтов и траблов, но я за то, чтобы эти конфликты видеть сразу, а не ждать, пока все ветки проекта сведутся в одну, и вылезут все баги. Мы все это уже проходили, когда приемка недельной работы сводится к двухдневной актуализации всего и вся.
Но безусловно здесь есть и свои минусы, и ряд новых требований к методике работы. В частности, здесь просто необходимо вводить одновременное отображение кода во всех открытых редакторах (как в гугл.докс, когда кто-то редактирует документ, а другой видит код). И это не только вопрос актуальности данных, а еще и инструмент помощи другому программисту. Когда один просит помочь с кодом, ты не присылаешь ему актуальный листинг с исправлениями, а просто вносишь ему правки в код, а он видит в своем редакторе изменения.
В общем, повторюсь, это чисто мое видение. В любом случае, для себя я уже гит прошел и оставил позади. Конечно пользуюсь им еще, но редко и в отдельных ситуациях.
Если кто захочет возразить по поводу продакшена и дер-проекта: конечно я за то, чтобы доработки вести в дев-версии. А перенос изменений — это уже вопрос системы пакетов MODX-а. То есть после окончания работ, на дев-версии готовится патч и заливается обновлением на продакшен. Процессс обновления обычно не занимает больше двух секунд, так что сбоев в работе как правило нет совершенно.
конечно, в некоторых ситуациях это может быть удобно, но не значит, что это всегда подходит.Так ктож с этим спорит? А иначе нафига нужно было бы столько языков программирования, ЦМСок и т.п.?
Но как только эти проекты сводятся в единую версию, кто вам может гарантировать, что конфликтов не будет? Никто. Только на практике уже будет видно есть конфликты или нет. И, кстати, в данном случае совершенно нет гарантии в том, что эти два программиста не работали над одним и тем же классом, и один не сломал что-то важное для другого.
Ваша пепяка только всё усугубляет, в Вашем же примере. Если два человека что-то разрабатывают, это не значит, всё глухо отправляется мержиться, абы как, на продакшене.
В случае с git, hg или любой другой VCS, конфликты — это нормально, кто-то скажет, что хорошо, а в вашем случае — смертельно опасно. Если в первом случае я могу разрулить конфликты как угодно, то в Вашем — кто последний залил, тот и победил, получается так? Или я неверно понимаю идеологию этого Web IDE в ModX? А что с самим контролем версий, в принципе все глухо уходит в релиз без возможности откатиться, если потребуется?
То есть после окончания работ, на дев-версии готовится патч и заливается обновлением на продакшен. Процессс обновления обычно не занимает больше двух секунд, так что сбоев в работе как правило нет совершенно.
Патчи гарантируют отсутствие конфликтов? Как они накатываются, заменой файлов?
У Вас представление обо всем этом, как мне показалось, как у человека, который один работает над одним небольшим проектом, капая в одну сторону, ну или максимум в связке с дизайнером, который в Ваши дебри и не лезет. Все Ваши высказывания подходят к маленьким задачам, но не большим, разработка которых может вестись параллельно с другими маленькими задачами и нести в себе глобальные изменения, которые потом могут оказаться вообще неудачными и провальными.
Или я неверно понимаю идеологию этого Web IDE в ModX? А что с самим контролем версий, в принципе все глухо уходит в релиз без возможности откатиться, если потребуется?
Смотрите, в данном случае я вообще считаю неправильно оперировать понятиями Ветка и т.п. Это всегда один единственный проект. Все работают только на нем. Здесь нет мержинга и т.п.
А что с самим контролем версий, в принципе все глухо уходит в релиз без возможности откатиться, если потребуется?MODX строится на пакетах, каждый со своей версией и т.п. По хорошему всегда есть предыдущие версии пакетов, возможность откатиться и т.п.
Пара скриншотов
Собственно, по этой причине я и ушел от гита. В MODX все очень локализовано в рамках каждого пакета в отдельности, что и контролировать при правильном подходе почти нечего. Любое изменение практически сразу видно, работает оно или нет. А API обеспечивает взаимодействие модулей, но не жесткую интеграцию их между собой. То есть если твой пакет работает хорошо, то он работать будет везде и со всеми модулями хорошо.
А за счет того, что я могу теперь работать он-лайн, без локальной IDE и использования всяких гитов и т.п., я полностью отвязался от своего рабочего места. Я запросто могу сесть за любой компьютер и работать с проектом, лишь бы браузер был и интернет. Я могу запросто ехать куда угодно, даже без компьютера :-)
Если отбрасывать все плюсы VCS, совместную разработку, а не установку готовых модулей, и тестирование до внедрения, то да, Ваш способ крутой и он мне нравится.
Спасибо!
Вот только не хотелось переводить акцент на свои решения. Я всего лишь хотел показать, что MODX является хорошим фреймворком. Не по сравнению с другими, а просто хорошим. А доводы выше складываются из простого непонимания его. Но как можно говорить про что-то, не зная и не понимая сути вещей?
Вот только не хотелось переводить акцент на свои решения. Я всего лишь хотел показать, что MODX является хорошим фреймворком. Не по сравнению с другими, а просто хорошим. А доводы выше складываются из простого непонимания его. Но как можно говорить про что-то, не зная и не понимая сути вещей?
Cloud9 прекрасно поддерживает git, и сами разработчики Cloud9 работают в ней же. С использованием git, естественно.
Я уже успел немного попользоваться этим сервисом, hg, кстати, тоже поддерживается, через bitbucket. Еще поддерживается FTP, у меня на работе многие порты закрыты, поэтому на другие проекты можно попадать и напрямую по FTP, правда, не разбирался с кодировкой, не нашел никаких менюшек со сменой кодировки.
Ой, сколько всего произошло в этом топике. Много всего сказали без меня, но я всё-таки отвечу, без картинок, только по делу.
В настоящих фреймворках в принципе не существует проблем, которые в MODX приходится мучительно решать и изворачиваться. Причина проста — при создании MODX авторы решали вполне конкретные задачи, и в списке не было задачи сделать фреймворк. Была задача сделать гибкий CMS. Однако, с гибкостью переборщили.
В итоге получилось так, что юзеры боятся MODX, как огня (это не пустая болтовня, а реальные жалобы представителей различных компаний, которым делали сайты на MODX), потому что из коробки админка страшна и непонятна. Да, есть умельцы, которые пилят свою админку, но зачем тогда CMS? Юзерам нужно удобство и лёгкость использования системы. В MODX Revo этого нет. Доказано рыдающими юзерами.
Программисты же, имеющие опыт работы с различными платформами и фреймворками (на PHP, C#, Java), от соприкосновения с MODX испытывают смесь недоумения с брезгливостью — как это могло появиться на свет?
Рабочий цикл обычного разработчика следующий:
* выбрал кейс из трекера
* разработал фичу/пофиксил багу
* проверил изменения локально
* залил в репозиторий
Деплоймент на тест/продакшн должен быть полностью автоматизирован, никаких манипуляций в веб-редакторах, «предварительных ласк» и зачисток конфигов.
Всё вышеописанное справедливо даже для сайтов-визиток, т.к. посмотреть историю коммитов с линками на кейсы в трекере всегда полезно.
Напоследок отмечу, что по профилю на хабре невозможно оценить мой уровень. Опубликованные статьи — это просто статьи.
В настоящих фреймворках в принципе не существует проблем, которые в MODX приходится мучительно решать и изворачиваться. Причина проста — при создании MODX авторы решали вполне конкретные задачи, и в списке не было задачи сделать фреймворк. Была задача сделать гибкий CMS. Однако, с гибкостью переборщили.
В итоге получилось так, что юзеры боятся MODX, как огня (это не пустая болтовня, а реальные жалобы представителей различных компаний, которым делали сайты на MODX), потому что из коробки админка страшна и непонятна. Да, есть умельцы, которые пилят свою админку, но зачем тогда CMS? Юзерам нужно удобство и лёгкость использования системы. В MODX Revo этого нет. Доказано рыдающими юзерами.
Программисты же, имеющие опыт работы с различными платформами и фреймворками (на PHP, C#, Java), от соприкосновения с MODX испытывают смесь недоумения с брезгливостью — как это могло появиться на свет?
Рабочий цикл обычного разработчика следующий:
* выбрал кейс из трекера
* разработал фичу/пофиксил багу
* проверил изменения локально
* залил в репозиторий
Деплоймент на тест/продакшн должен быть полностью автоматизирован, никаких манипуляций в веб-редакторах, «предварительных ласк» и зачисток конфигов.
Всё вышеописанное справедливо даже для сайтов-визиток, т.к. посмотреть историю коммитов с линками на кейсы в трекере всегда полезно.
Напоследок отмечу, что по профилю на хабре невозможно оценить мой уровень. Опубликованные статьи — это просто статьи.
| Напоследок отмечу, что по профилю на хабре невозможно оценить мой уровень. Опубликованные статьи — это просто статьи.
Но по этому комменту можно продолжать уверенно утверждать, что MODX-а вы не знаете.
Остальное без комментариев в силу этой же причины. Продолжайте слушать «рыдающих юзеров».
Но по этому комменту можно продолжать уверенно утверждать, что MODX-а вы не знаете.
Остальное без комментариев в силу этой же причины. Продолжайте слушать «рыдающих юзеров».
Так ведь всё дело в том, что я и не хочу узнавать MODX дальше! Бесперспективно.
Я же в своём первом комментарии написал, что мы сделали тестовый сайт на MODX, чтобы его изучить. Тест-драйва хватило, чтобы понять, что на этом движке нам больше ничего не надо. Салон, вроде бы кожаный и кондиционер есть, но вход через крышу, восемь педалей и три руля. Чтобы научиться пользоваться, нужно получать новые права неизвестной категории.
Собственно, заказчика, для которого проводился тест, движок тоже не устроил. Ни производительность (на выделенном сервере с очень неслабой конфигурацией), ни админка. Выкинули MODX с облегчением.
Я же в своём первом комментарии написал, что мы сделали тестовый сайт на MODX, чтобы его изучить. Тест-драйва хватило, чтобы понять, что на этом движке нам больше ничего не надо. Салон, вроде бы кожаный и кондиционер есть, но вход через крышу, восемь педалей и три руля. Чтобы научиться пользоваться, нужно получать новые права неизвестной категории.
Собственно, заказчика, для которого проводился тест, движок тоже не устроил. Ни производительность (на выделенном сервере с очень неслабой конфигурацией), ни админка. Выкинули MODX с облегчением.
| Так ведь всё дело в том, что я и не хочу узнавать MODX дальше! Бесперспективно.
Так вот как раз с этим я и не буду спорить! И не буду вас убеждать в обратном, мол, вернитесь, одумайтесь и т.п.
Но что получается? Вы не освоили этот движок, и навесили на него клеймо, выдавая за истину. Вы «не получили новые права», и рассуждаете о том, кто там прав а кто нет.
Да, потолок вхождения действительно высок, и многим покажется действительно не перспективным такое изучение, но я изучил, я знаю эту систему очень и очень хорошо. Я не редко спорю с главным архитектором системы и не безрезультатно. И у меня есть много оснований утверждать, что вы не знаете эту систему и ваши утверждения ошибочны и безосновательны.
Так вот как раз с этим я и не буду спорить! И не буду вас убеждать в обратном, мол, вернитесь, одумайтесь и т.п.
Но что получается? Вы не освоили этот движок, и навесили на него клеймо, выдавая за истину. Вы «не получили новые права», и рассуждаете о том, кто там прав а кто нет.
Да, потолок вхождения действительно высок, и многим покажется действительно не перспективным такое изучение, но я изучил, я знаю эту систему очень и очень хорошо. Я не редко спорю с главным архитектором системы и не безрезультатно. И у меня есть много оснований утверждать, что вы не знаете эту систему и ваши утверждения ошибочны и безосновательны.
Всё верно, но я про восемь педалей и три руля не просто так написал. Этим сравнением я хотел показать необоснованную запутанность и сложность MODX. Есть такое высказывание:«Просто сделать сложно. Сложно сделать просто». Как раз про MODX.
Идея в том, что тест-драйв — достаточно показательная вещь. Когда простые вещи приходится делать сложными и неочевидными способами, это явный признак плохой архитектуры продукта. Ещё раз поясню, что я далеко не новичок и имею многолетний опыт разработки на различных платформах и в различных командах (как сидящих в одном офисе, так и в распределённых по нескольким странам), поэтому в состоянии провести трезвую оценку.
Вы ничего не ответили про рабочий цикл разработчика, посчитав, что если я пишу о «рыдающих клиентах», то и дальше разговаривать не о чем. Однако, к MODX это не имеет никакого отношения. Практически любой программный продукт так разрабатывается. И самая большая проблема как раз в том, что разработка чего-либо на MODX не ложится на этот годами устоявшийся процесс. Вам не зря хохочущих мужиков показывали, когда вы начали высказывать претензии к git, продемонстрировав тем самым крайнюю узость своей специализации и полное непонимание необходимости наличия системы контроля версий как таковой.
Идея в том, что тест-драйв — достаточно показательная вещь. Когда простые вещи приходится делать сложными и неочевидными способами, это явный признак плохой архитектуры продукта. Ещё раз поясню, что я далеко не новичок и имею многолетний опыт разработки на различных платформах и в различных командах (как сидящих в одном офисе, так и в распределённых по нескольким странам), поэтому в состоянии провести трезвую оценку.
Вы ничего не ответили про рабочий цикл разработчика, посчитав, что если я пишу о «рыдающих клиентах», то и дальше разговаривать не о чем. Однако, к MODX это не имеет никакого отношения. Практически любой программный продукт так разрабатывается. И самая большая проблема как раз в том, что разработка чего-либо на MODX не ложится на этот годами устоявшийся процесс. Вам не зря хохочущих мужиков показывали, когда вы начали высказывать претензии к git, продемонстрировав тем самым крайнюю узость своей специализации и полное непонимание необходимости наличия системы контроля версий как таковой.
Когда замучаетесь сводить ветки, тогда может и посмотрите на гит по-другому.
По всему остальному, так и оставлю без комментариев. Принцип «я не понял, по-этому это говно» не вызывает желания продолжать диалог.
По всему остальному, так и оставлю без комментариев. Принцип «я не понял, по-этому это говно» не вызывает желания продолжать диалог.
«Веточные мучения» — это, видимо, следствие работы с MODX. Я много лет работаю без проблем с SVN/TFS/Mercurial/Git.
Вы просто не понимаете, что такое спокойно бэкпортить фиксы в три бранча, т.к. у кастомеров разные версии продукта, а фикс нужен всем, но апгрейдиться на следующий мажорный релиз они пока не могут, т.к. очень много бизнес-процессов завязано.
Очевидно, работа такого масштаба немыслима в веб-редакторе. Что такое тысячи юнит-тестов на каждый коммит на билд-сервере, полагаю, для вас тоже загадка.
Вы просто не понимаете, что такое спокойно бэкпортить фиксы в три бранча, т.к. у кастомеров разные версии продукта, а фикс нужен всем, но апгрейдиться на следующий мажорный релиз они пока не могут, т.к. очень много бизнес-процессов завязано.
Очевидно, работа такого масштаба немыслима в веб-редакторе. Что такое тысячи юнит-тестов на каждый коммит на билд-сервере, полагаю, для вас тоже загадка.
Да, я тоже много страшных слов знаю.
Попробуйте со всем этим подходом проект за 5 000 рублей выполнить.
Попробуйте со всем этим подходом проект за 5 000 рублей выполнить.
Спасибо, даже пробовать не буду. Одна только работа веб-дизайнера обойдётся в несколько раз дороже.
Вот именно. Потому продолжайте использовать свои проверенные технологии. А я думаю не только о технологиях, но и об оптимизации издержек, снижении себестоимости продукта и в итоге — конечной стоимости для клиента.
Я не говорил, что гит — это плохо. Я сказал, что для меня это вчерашний век, так как те методологии, которые я выбрал для себя в последнее время, позволили мне сократить время разработки до нескольких раз, сократить количество участников проекта, и облегчили сопровождение проекта. Мне не надо платить большие деньги таким сотрудникам как вы, только потому что вы знаете много страшных слов и умеете водить танк при охоте на мух. Мне не нужны VDS и т.п., достаточно простейшего шаредхостинга и т.д. и т.п.
Это веб-индустрия, и это далеко не всегда глобальные огромные проекты. Работа на едином проекте без ветвления его по личным персональным компьютерам, выделения отдельного специалиста для правления всего этого и т.п. — отличная альтернатива. А на продакшен накатывается простой патч, без каких-либо конфликтов, так как то, что работает на точной копии проекта, то будет работать и на самом проекте.
Итог: у нас разные рынки, и разные подходы к работе.
Я не говорил, что гит — это плохо. Я сказал, что для меня это вчерашний век, так как те методологии, которые я выбрал для себя в последнее время, позволили мне сократить время разработки до нескольких раз, сократить количество участников проекта, и облегчили сопровождение проекта. Мне не надо платить большие деньги таким сотрудникам как вы, только потому что вы знаете много страшных слов и умеете водить танк при охоте на мух. Мне не нужны VDS и т.п., достаточно простейшего шаредхостинга и т.д. и т.п.
Это веб-индустрия, и это далеко не всегда глобальные огромные проекты. Работа на едином проекте без ветвления его по личным персональным компьютерам, выделения отдельного специалиста для правления всего этого и т.п. — отличная альтернатива. А на продакшен накатывается простой патч, без каких-либо конфликтов, так как то, что работает на точной копии проекта, то будет работать и на самом проекте.
Итог: у нас разные рынки, и разные подходы к работе.
Вот за постоянные наезды личные вам карму и слили. Что ещё за «много страшных слов» и «вождение танка»? Слова не страшные, а вполне обычные, каждый день так разговариваю.
Я правильно понимаю, что вы отрицаете системы контроля версий (специально не пишу гит, т.к. их много), потому что не можете ими толком пользоваться и видите в них не пользу, а сплошную головную боль? Это ведь спор слепого с глухим получается тогда…
А про шаред хостинг и MODX просто смешно уже — вы нагрузочное тестирование вообще проводили на этих шаредах? Там же 5-7 запросов в секунду будет, максимум, и то если закешировать вообще всё.
Про рынки… если даже весь проект длится всего месяц, а потом через год ему понадобится какая-то поддержка, то кейсы в трекере и история в репозитории очень сильно поможет вспомнить, что ж там было. Поэтому я только частично могу согласиться про разные рынки.
Я правильно понимаю, что вы отрицаете системы контроля версий (специально не пишу гит, т.к. их много), потому что не можете ими толком пользоваться и видите в них не пользу, а сплошную головную боль? Это ведь спор слепого с глухим получается тогда…
А про шаред хостинг и MODX просто смешно уже — вы нагрузочное тестирование вообще проводили на этих шаредах? Там же 5-7 запросов в секунду будет, максимум, и то если закешировать вообще всё.
Про рынки… если даже весь проект длится всего месяц, а потом через год ему понадобится какая-то поддержка, то кейсы в трекере и история в репозитории очень сильно поможет вспомнить, что ж там было. Поэтому я только частично могу согласиться про разные рынки.
Так как бы на карму мне пофиг. Я никого не умолял не сливать мне карму. Это же детский сад, все эти кармы.
| Я правильно понимаю, что вы отрицаете системы контроля версий
Я вообще не знаю что и как вы понимаете. Я достаточно ясно выразился — есть разные методологии разработки, и контроль версий и т.п. имеет обыкновение существенно усложнить разработку там, где это не нужно, и тем самым плюс ко всему и себестоимость увеличить. Мне не важно как вы работаете, это ваше дело, я сказал как я работаю, и меня это вполне устраиваю.
| Там же 5-7 запросов в секунду будет, максимум, и то если закешировать вообще всё.
Чел, я не знаю чем и как ты занимаешься (уже на вы никак не получается), но я весь биллинг сотовой компании держал, и с Ораклом работать начал раньше, чем с мускулом и т.п. Не надо мне про тесты и запросы заливать. Иди гиты свои крути, а у меня запросы на сотнях тысяч записей за тысячные секунды выполняются.
Все, диалог закрыт. Задолбался бисер перед свиньями метать.
| Я правильно понимаю, что вы отрицаете системы контроля версий
Я вообще не знаю что и как вы понимаете. Я достаточно ясно выразился — есть разные методологии разработки, и контроль версий и т.п. имеет обыкновение существенно усложнить разработку там, где это не нужно, и тем самым плюс ко всему и себестоимость увеличить. Мне не важно как вы работаете, это ваше дело, я сказал как я работаю, и меня это вполне устраиваю.
| Там же 5-7 запросов в секунду будет, максимум, и то если закешировать вообще всё.
Чел, я не знаю чем и как ты занимаешься (уже на вы никак не получается), но я весь биллинг сотовой компании держал, и с Ораклом работать начал раньше, чем с мускулом и т.п. Не надо мне про тесты и запросы заливать. Иди гиты свои крути, а у меня запросы на сотнях тысяч записей за тысячные секунды выполняются.
Все, диалог закрыт. Задолбался бисер перед свиньями метать.
Красота :) Какая связь между биллингом на Оракле и MODX?! Я даже спорить не буду, что биллинг на Оракле — это то, что доктор прописал.
Мне казалось, что в данной дискуссии мы не членами меряемся, а обсуждаем факты, что MODX не является фреймворком, безбожно тормозит, неудобна для конечных пользователей и т.д.
Исходя из аргументов вида «иди гит крути» и «да я биллинг на оракле держал» — вы со мной втайне согласны с вышеперечисленными тезисами :) Предыдущие аргументы в виде скриншотов из админки тоже не аргументы не тянут, т.к. в основном демонстрировали небольшие участки продукта, не отражая картины в целом.
Привет биллингам и бисеру.
Мне казалось, что в данной дискуссии мы не членами меряемся, а обсуждаем факты, что MODX не является фреймворком, безбожно тормозит, неудобна для конечных пользователей и т.д.
Исходя из аргументов вида «иди гит крути» и «да я биллинг на оракле держал» — вы со мной втайне согласны с вышеперечисленными тезисами :) Предыдущие аргументы в виде скриншотов из админки тоже не аргументы не тянут, т.к. в основном демонстрировали небольшие участки продукта, не отражая картины в целом.
Привет биллингам и бисеру.
euro-shina-ru.fi1osof.modxcloud.com/avtoshinyi/podbor-po-razmeram/
30 000 товаров/документов. 250 000 записей TV-параметров. Каталог не из кеша. Тормозит?
А еще берем во внимание время на его разработку — 35-40 часов.
30 000 товаров/документов. 250 000 записей TV-параметров. Каталог не из кеша. Тормозит?
А еще берем во внимание время на его разработку — 35-40 часов.
$ siege "http://euro-shina-ru.fi1osof.modxcloud.com/avtoshinyi/podbor-po-razmeram/?width=33&visota_profila=&diametr=15&sezonnost=1&price1=&price2=&start=OK"
Lifting the server siege... done. Transactions: 472 hits
Availability: 100.00 %
Elapsed time: 81.93 secs
Data transferred: 2.08 MB
Response time: 3.39 secs
Transaction rate: 5.76 trans/sec
Throughput: 0.03 MB/sec
Concurrency: 19.54
Successful transactions: 472
Failed transactions: 0
Longest transaction: 3.96
Shortest transaction: 0.95
Да и время генерации страницы 0.6851s не мало.
Это вполне нормальное время для такого количества страниц, тем более, что это еще черновой вариант. Повторяюсь, на разработку этого было потрачено не более сорока часов. Еще многое не доделано. Можете сравнить производительность с оригиналом: www.euro-shina.ru/ (вот там действительно скорость не приемлемая). В дальнейшем скорость генерации страницы еще будет увеличена, проект еще в разработке.
Кстати, если Вы сделали проект, передали его, после завершения разработки, там поручили управлять какому-нибудь местному программисту-администратору и он удаляет, просто по ошибке удаляет часть кода, который был не из какого-то пакета установлен, а написан специально для этого проекта в веб редакторе Вами же. Как тогда восстановить удаленную информацию, есть какие-то решения в этом плане? Или при запуске проекта возможность редактирования файлов проектов отключается?
Думаю, это для многих будет полезной информацией, хотя бы потому, что кто-то сможет полностью избавить себя от хранения дев версии, использования контроля версий и многих других, очевидно, лишних вещей.
Думаю, это для многих будет полезной информацией, хотя бы потому, что кто-то сможет полностью избавить себя от хранения дев версии, использования контроля версий и многих других, очевидно, лишних вещей.
Вы плохо читали текст выше. Желание посмеяться притупляло возможное желание понять что-нибудь.
Я говорил, что в MODX используется система пакетов. В моем modxSDK так же используется сборщик пакетов.
После того, как выполняется необходимая работа, просто собирается пакет, заливается на продакшен и устанавливается в пару кликов. И даже если по какой-то удивительной причине что-то сломается, можно откатиться на предыдущую версию пакета.
Я говорил, что в MODX используется система пакетов. В моем modxSDK так же используется сборщик пакетов.
После того, как выполняется необходимая работа, просто собирается пакет, заливается на продакшен и устанавливается в пару кликов. И даже если по какой-то удивительной причине что-то сломается, можно откатиться на предыдущую версию пакета.
Как говорил кто-то — если у вас есть ружье и вы хотите отстрелить себе ногу, то вам никто не сможет помешать. Здесь все тоже самое, администратор сможет запросто сделать гадость, если у него на это есть права. Но их можно ограничить и упростить жизнь.
С другой стороны наладить контроль версий для нормального проекта не помешает, а также никто не отменял бэкапы.
То есть работать всегда на продакшене? Это может создать множество щекотливых моментов на практике.
С другой стороны наладить контроль версий для нормального проекта не помешает, а также никто не отменял бэкапы.
что кто-то сможет полностью избавить себя от хранения дев версии, использования контроля версий и многих других, очевидно, лишних вещей.
То есть работать всегда на продакшене? Это может создать множество щекотливых моментов на практике.
Так, вроде, Вы все эти товары разом и не выводите. Поиска там тоже нет, можно было бы оценить работу по нему, если, конечно, не были использованы какие-то системы, типа, Сфинкса.
фильтр который не отфильтровывает несуществующие комбинации это вообще никуда не годится
Кого я вижу :-)
1. Мы обсуждаем производительность, а не тонкости бизнес-логики проекта.
2. Покажи свой мегапроект, крупный и производительный. И подскажи, сколько часов на его разработку потратил.
1. Мы обсуждаем производительность, а не тонкости бизнес-логики проекта.
2. Покажи свой мегапроект, крупный и производительный. И подскажи, сколько часов на его разработку потратил.
1 какая тут производительность?
Memory: 24.25 Mb TotalTime: 0.6805 s
при 30 000 то тыс? это быстрее чем оригинал но все равно это не тот результат который удовлетворит нормального клиента. Еще замечу что проект на modxcloud. тоесть на простом шаред хостинге результат будет хуже.
Я верю что Вы можете сделать хорошо и качесвенно и что MODX REVO это позволяет. Но не нужно показывать сырой вариант так как там есть куча ляпов на которые вы само собой будете отвечать что виноваты не вы а другие, к примеру на прошлый комментарий вы пожаловались на бизнес логику.
2. Да все никак не доделаю демо сайт на 100к товаров с 10 характеристиками у каждого
как доделаю обязательно будет обзор
Memory: 24.25 Mb TotalTime: 0.6805 s
при 30 000 то тыс? это быстрее чем оригинал но все равно это не тот результат который удовлетворит нормального клиента. Еще замечу что проект на modxcloud. тоесть на простом шаред хостинге результат будет хуже.
Я верю что Вы можете сделать хорошо и качесвенно и что MODX REVO это позволяет. Но не нужно показывать сырой вариант так как там есть куча ляпов на которые вы само собой будете отвечать что виноваты не вы а другие, к примеру на прошлый комментарий вы пожаловались на бизнес логику.
2. Да все никак не доделаю демо сайт на 100к товаров с 10 характеристиками у каждого
как доделаю обязательно будет обзор
1. Это вполне нормальная производительность. Я ее в дальнейшем еще улучшу, так как сейчас из-за структуры, которая унаследована от старого сайта, приходится в запросах джойнить родителей и их родителей (модели и производители), чтобы проверять на актуальность документы. То есть если будет снят с публикации производитель, то из выдачи выпадут все его модели и конечные товары.
Но производительность все равно ИМХО нормальная. Для меня нормально, если код каталога отдается менее, чем за секунду. В данном случае я оцениваю как конечный пользователь, а не оверклокер.
2. Я думаю, что этот на 100к еще не скоро будет доделан. Вот мой сырой вариант готов за 40 часов. А сколько часов потрачено на тот неготовый сайт? А главное, сколько хаков ядра для этого выполняется, особенно для решения проблем с кешем? Этот же сайт тоже изначально на Эво был. Вот пара основных проблем, связанных с этим. Там на запуск сайта 156 метров минимум надо было (это на 30к товаров). А на 100к сколько памяти понадобится? Только не надо про кривые руки и т.п. Если не хакнуть систему кеширования и Эва как положено все набьет в кеш, то при 100к. кеш-файл будет огромный. Ну и конечно есть вариант делать это не на документах, чтобы в кеш не лезли. Но тогда нет нативного роунинга, нативных политик доступов для менеджеров, TV-параметров и т.п. Думаю, счет часов работы пойдет на сотни, а объем кода на тысячи и десятки тысяч строк.
Но производительность все равно ИМХО нормальная. Для меня нормально, если код каталога отдается менее, чем за секунду. В данном случае я оцениваю как конечный пользователь, а не оверклокер.
2. Я думаю, что этот на 100к еще не скоро будет доделан. Вот мой сырой вариант готов за 40 часов. А сколько часов потрачено на тот неготовый сайт? А главное, сколько хаков ядра для этого выполняется, особенно для решения проблем с кешем? Этот же сайт тоже изначально на Эво был. Вот пара основных проблем, связанных с этим. Там на запуск сайта 156 метров минимум надо было (это на 30к товаров). А на 100к сколько памяти понадобится? Только не надо про кривые руки и т.п. Если не хакнуть систему кеширования и Эва как положено все набьет в кеш, то при 100к. кеш-файл будет огромный. Ну и конечно есть вариант делать это не на документах, чтобы в кеш не лезли. Но тогда нет нативного роунинга, нативных политик доступов для менеджеров, TV-параметров и т.п. Думаю, счет часов работы пойдет на сотни, а объем кода на тысячи и десятки тысяч строк.
1. Вот я про тоже Вы можете сделать лучше но показывая сырой вариант многие думают что это предел возможностей, потому и складывается обманчивое впечатление.
2. На 100к уже доделан и даже сдан сайт клиенту но так как это будет позиционироваться как готовый продукт то нужно и сделать под него красивый демо сайт потому надеюсь что руки дойдут скоро (хотя тут как всегда для клиентов делаешь быстро а для себя медленно)
— хаков ядра нет ни одного
— делать подобное на дереве документов не целесообразно потому сделанно на отдельной таблице
— памяти на 100к кушает 4mb
— роутинг не страдает так как можно сделать красиво всего строк 10 кода под это дело
— политики доступа не есть проблемой использовать можно встроенные в MODX EVO
— тв параметры и все остальное используется так как убирать гибкость системы это в корню не верный подход:)
вообщем получилос красиво и удобно осталось навести марафет
2. На 100к уже доделан и даже сдан сайт клиенту но так как это будет позиционироваться как готовый продукт то нужно и сделать под него красивый демо сайт потому надеюсь что руки дойдут скоро (хотя тут как всегда для клиентов делаешь быстро а для себя медленно)
— хаков ядра нет ни одного
— делать подобное на дереве документов не целесообразно потому сделанно на отдельной таблице
— памяти на 100к кушает 4mb
— роутинг не страдает так как можно сделать красиво всего строк 10 кода под это дело
— политики доступа не есть проблемой использовать можно встроенные в MODX EVO
— тв параметры и все остальное используется так как убирать гибкость системы это в корню не верный подход:)
вообщем получилос красиво и удобно осталось навести марафет
1. У многих складывается обманчивое впечатление из-за непонимания многих вещей в принципе.
Но вот можно посмотреть более законченный проект: www.factum-doors.ru/
Там правда всего 13 000 товаров, но все равно в целом не мало.
2. На дереве ресурсов не целесообразно в Эво, так как там нет такого как «Не показывать в дереве», а в Рево очень даже целесообразно, так как TV-параметры привязываются к шаблонам, и чтобы у документы в редакторе выводился нужный набор TV-параметров, ему надо указать соответствующий шаблон. А если у вас не используется документ, то и назначить шаблон без хаков вы не можете.
Праава доступов к документам в MODX основываются на группах ресурсов. Соответственно если вы не использовали документы, а просто свои «записи», то нет распределения прав на конкретные документы. Можно использовать глобальные уровни, типа Можно редактировать документы или нет, но нельзя указать что эти документы можно редактировать, а эти нет.
В общем, конечно это напрямую не связано с производительностью. Если все быстро работает и т.п., то все клево. Но ведь и вопрос трудозатрат на это тоже немаловажный. Можно то и с нуля все написать, и тоже будет быстро работать и т.п., но времени все-таки на это уйдет больше. Потому я использую полностью нативные технологии MODX-а (документы, шаблоны, TV-параметры и т.п.).
Но вот можно посмотреть более законченный проект: www.factum-doors.ru/
Там правда всего 13 000 товаров, но все равно в целом не мало.
2. На дереве ресурсов не целесообразно в Эво, так как там нет такого как «Не показывать в дереве», а в Рево очень даже целесообразно, так как TV-параметры привязываются к шаблонам, и чтобы у документы в редакторе выводился нужный набор TV-параметров, ему надо указать соответствующий шаблон. А если у вас не используется документ, то и назначить шаблон без хаков вы не можете.
Праава доступов к документам в MODX основываются на группах ресурсов. Соответственно если вы не использовали документы, а просто свои «записи», то нет распределения прав на конкретные документы. Можно использовать глобальные уровни, типа Можно редактировать документы или нет, но нельзя указать что эти документы можно редактировать, а эти нет.
В общем, конечно это напрямую не связано с производительностью. Если все быстро работает и т.п., то все клево. Но ведь и вопрос трудозатрат на это тоже немаловажный. Можно то и с нуля все написать, и тоже будет быстро работать и т.п., но времени все-таки на это уйдет больше. Потому я использую полностью нативные технологии MODX-а (документы, шаблоны, TV-параметры и т.п.).
Подождите, какие 5 тысяч рублей? Я по одной и ссылок читал, что вы специалист по высоконагруженным решениям)
1. Я не один, и мне есть куда спустить небольшой проект ниже, если надо.
2. Есть постоянные клиенты, которым нельзя отказать. Но сайт за 5000 я за день могу сделать (если дизайн есть (и лучше если еще и верстка)). Это тоже не за бесплатно работа.
2. Есть постоянные клиенты, которым нельзя отказать. Но сайт за 5000 я за день могу сделать (если дизайн есть (и лучше если еще и верстка)). Это тоже не за бесплатно работа.
А есть проекты масштабные, которые Вы сопровождаете или разрабатываете?
Что вы подразумеваете под масштабными проектами?
Но в целом, не могу сказать, что у меня в копилке есть действительно крупные проекты. Каталоги на 20-30 тысяч товаров — это не крупный проект. Крупную социальную сеть я тоже еще не делал. У меня нет еще мощной команды, а в одного я не смогу выполнить действительно крупный проект. На это надо много времени и средств.
Но в целом, не могу сказать, что у меня в копилке есть действительно крупные проекты. Каталоги на 20-30 тысяч товаров — это не крупный проект. Крупную социальную сеть я тоже еще не делал. У меня нет еще мощной команды, а в одного я не смогу выполнить действительно крупный проект. На это надо много времени и средств.
P.S. Есть система заявок на пропуска, заявки ЖКХ и т.п., стоит в паре бизнес-центров. До обновления системы (предыдущая работала на MODX Evolution), с миллионом исторических записей заявок система вполне быстро работала с поиском без какого-либо кеширования при наборе по буквам. Отклик 15-25 милисек на Ajax-запросах.
Ну, видимо, с помощью поисковой системы какой-то)
При чем тут поисковая система?
А что Вы под поисковой системой понимаете, раз так удивились? Вы ищите средствами mySQL или какой-то другой БД по миллиону (или больше) записей без использования какого-то специального поискового ПО?
1. Да, ищу без специального ПО и т.п. Про сфинкс и т.д. можно не заливать.
2. Этот диалог мне не интересен и продолжать его не планирую. Никакого отношения мои способы поиска к MODX-у не имеют.
2. Этот диалог мне не интересен и продолжать его не планирую. Никакого отношения мои способы поиска к MODX-у не имеют.
Так понятно, что не интересен, раз не используете :) Ну ладно, я просто поинтересоваться хотел на решение.
Вот, опять Fi1osof порадовал — «про сфинкс можно не заливать» :)
Сайты на Сфинксе — очевидно, разработчики тупые, надо было искать по базе в лоб, а они зачем-то сфинкс прикрутили, лохи.
Сайты на Сфинксе — очевидно, разработчики тупые, надо было искать по базе в лоб, а они зачем-то сфинкс прикрутили, лохи.
Livestreet :)
Другое: onPHP
Это не framework
Разумеется, даже из названия Alto CMS видно что это CMS. Но ведь и Битрикс, Друпал, Джумла, ВП, что в списке указаны — это тоже не фреймворки, а CMS
Вообще, вы не совсем правы — Drupal и присловутый битрикс всё же CMF, т.е. специализированные фреймворки в итоге.
Ну если даже Битрикс — это «специализированный фреймворк», то Alto CMS — уж тем более! :)
А если серьезно, то, конечно, это никакие не фреймворки, что, впрочем, не мешает некоторым умельцам юзать их именно в этом качестве, строгая на них что угодно
А если серьезно, то, конечно, это никакие не фреймворки, что, впрочем, не мешает некоторым умельцам юзать их именно в этом качестве, строгая на них что угодно
Не скажу за Битрикс, но чем Друпал не фреймворк? Чего ему не хватает, по-вашему, чтобы называться фреймворком?
Возвращаясь к началу этой ветки могу спросить точно так же: а чем Alto CMS не фреймворк? :)
Грань между CMS и CMF весьма размыта, это давно известно. Сами разработчики Друпала позиционируют ее, как CMS. Но разумеется, его можно юзать, в качестве фреймворка, как и большинство других движков, называющих себя CMS.
Грань между CMS и CMF весьма размыта, это давно известно. Сами разработчики Друпала позиционируют ее, как CMS. Но разумеется, его можно юзать, в качестве фреймворка, как и большинство других движков, называющих себя CMS.
Конечно, лучше было б, если бы ТС уточнил, что он имел ввиду — либо речь о CMS/CMF вообще, либо о том, что какие-то CMS используются как фреймворки, что, в общем-то, не редкость
Другое NetCat
Другой: Laravel.
немного радует, что велосипедистов со своими фреймворками и без них поуменьшилось (по сравнению с прошлым опросом)
так лет через 10 может и вообще не будет
так лет через 10 может и вообще не будет
Так проголосовало только 500 человек, а там — около 2,5к.
Без велосипедов не будет понимания и опыта, многие от велосипедов дорастают до взрослых фреймворков потом, так что если они исчезнут, это будет не сильно хорошо.
Если бы каждый разработчик, который начал писать сразу с использованием фреймворка попробовал хоть раз написать свой велосипед (конечно, желательно для себя, чтоб не отравлять других разработчиков), то говнокода и вопросов, за которые хочется дать кулаком по лбу стало бы значительно меньше.
Не думал что тортиком мало кто пользуется) я в целом доволен
как правило подбираем фреймворк под задачу, щас Phalcon
PhalconPhp :)
Поддерживаю. В моей компании на нём несколько команд пишут.
А есть уже действующие проекты? На какой версии?
С какими проблемами столкнулись при разработке?
С какими проблемами столкнулись при разработке?
Я, к сожалению, не слишком компетентна в технических вопросах. Но вот мой коллега boston обязательно ответит на любые вопросы (он участник команды PhalconPHP)
Первый рабочий проект был на 0.4.5 с обновлением до 0.5.3, текущие на 1.1.0.
Проблемы были на самых первых этапах, когда использование свежий версий с github рушило некоторые не связанные с сайтом скрипты, в частности phpmyadmin вёл себя совсем не адекватно.
Была проблема с использованием подключений к разным базам в одном сценарии и при совпадении названий таблиц, но это поправили кажется дня за полтора.
Сейчас всё стабилизировалось, готовимся к 1.2.0 версии ;)
Проблемы были на самых первых этапах, когда использование свежий версий с github рушило некоторые не связанные с сайтом скрипты, в частности phpmyadmin вёл себя совсем не адекватно.
Была проблема с использованием подключений к разным базам в одном сценарии и при совпадении названий таблиц, но это поправили кажется дня за полтора.
Сейчас всё стабилизировалось, готовимся к 1.2.0 версии ;)
Удивляют позиции CodeIgniter-a. Скорее всего низкий порог входа и нежелание разработчиков учить новое
Меня больше удивляют позиции «Пишу на PHP, но не использую фреймворки».
Если все люди, которые проголосовали за это пишут узкоспециализированные модули для конкретной задачи и высокой нагрузки, если все эти люди могут аргументированно доказать, почему в данной ситуации лучше написать свой код и не использовать фреймворки, то тогда ситуация радует.
Однако, это не так.
Однако, это не так.
Использование сторонних CMS или фреймворков — это, как минимум, вступление в сложные правоотношения с третьими лицами. Многие хотят иметь исключительные права на используемый продукт.
Как сказала А. Макаров, один из разработчиков Yii, на DevConf — вы можете запаковать фреймворк в zip архив и продавать его.
Для правоотношений с третьими лицами придумали лицензии. MIT и BSD лицензии избавят вас от головной боли с правоотношениями. И зачем иметь исключительные права на инструмент, с помощью которого создан продукт?
Для правоотношений с третьими лицами придумали лицензии. MIT и BSD лицензии избавят вас от головной боли с правоотношениями. И зачем иметь исключительные права на инструмент, с помощью которого создан продукт?
Вы лично пробовали поставить на бухгалтерский и налоговый учет продукты с MIT или BSD в российских реалиях? И фреймворк это не IDE, чтобы говорить «с помощью» — это неотъемлемая часть продукта, его основа.
А зачем их ставить на этот учет?
Требования закона.
Так я про фреймворк. Продукт вы можете лицензировать по отличной от MIT лицензии.
Так я тоже про него. Есть фреймворк и есть продукт. Два актива, которые надо ставить на учет.
Фреймворк то зачем ставить? Расскажите пожалуйста подробнее причины.
Придет проверка, начнет рыть — в каталоге /app лежат файлы с копирайтами volch, а в каталоге lib — с другими, а документы только на volch.
И что, нам теперь, как Инфра-Ресурс-у продавать бумажки для OpenSource-продуктов?
Вариантов решения множество, если хотите сделать вид, что соблюдаете российское законодательство. Если хотите его полностью соблюдать, то не уверен, что продажа бумажек что-нибудь значит, если за вас серьезно возьмутся. Моим VIP-заказчикам я не советую таким заниматься, а советую всё оформлять отдельно (в разумных пределах — Ubuntu или Mandriva оформляются как единый продукт).
Однако на практике многие компании живут тем, что пишут платные модули и компоненты для бесплатных фреймворков и cms. Продается не фреймворк ведь, а тот код, который написала сама студия.
Не использовать никакие опенсорсные продукты и писать всё с нуля, боясь каких-то проблем с налоговой — имхо, что-то отдаленное от реальности. Если бы действительно была хоть в какой-то степени серьезная угроза со стороны налоговой, то фреймворки у нас бы использовали одни фрилансеры. Однако, это не так, если посмотреть хотя бы на требования в вакансиях на hh.
Не использовать никакие опенсорсные продукты и писать всё с нуля, боясь каких-то проблем с налоговой — имхо, что-то отдаленное от реальности. Если бы действительно была хоть в какой-то степени серьезная угроза со стороны налоговой, то фреймворки у нас бы использовали одни фрилансеры. Однако, это не так, если посмотреть хотя бы на требования в вакансиях на hh.
В случае серьёзного highload'а workflow популярных фреймворков попросту непригодно к актуальным нуждам, вне зависимости от ЯП.
Спорить по этому поводу можно долго и упорно. Как пример — Yii достаточно быстр, и очень неплохо настраивается под highload. 2GIS, в частности, его использует для разработки своих сервисов.
2GIS — это в первую очередь поиск (который, очевидно, не на php делается) и статические данные — в этом случае не важно, что использовать. Я всё-таки про большие интерактивные сервисы для миллионов пользователей.
Не вижу, чем именно вам тут помешает фреймворк. Вы же не собираетесь такие сервисы вытягивать в один сервер?
Фрейморк — ничем не помешает. Так же как и не поможет — шардинг, распределённые блокировки, многоуровневое хранение и кеширование данных, распределённая шина событий, демоны, отложенное исполнение задач, итд — всего этого распространённые фреймворки не умеют — другие цели и задачи.
Поможет с «мелочами» типа валидации и роутинга. Нет?
Роутинг? — regexp'ы по количеству контроллеров хоть в nginx'е?
Валидация? — десяток статических методов?
Да, это всё можно обернуть в красивый ООП, сделать удобное API, неявный вызов, xml-конфиги и прочий интерпрайз — просто в минимально-необходимой реализации это и правда мелочи.
Валидация? — десяток статических методов?
Да, это всё можно обернуть в красивый ООП, сделать удобное API, неявный вызов, xml-конфиги и прочий интерпрайз — просто в минимально-необходимой реализации это и правда мелочи.
Собственно для отсутствия этих мелочей фреймворки и создаются, имхо. Чтобы не отвлекали они от бизнес-логики и «шардинг, распределённые блокировки, многоуровневое хранение и кеширование данных, распределённая шина событий, демоны, отложенное исполнение задач, итд».
Фреймворк создаётся, чтобы конечный программист реализовывал бизнес-логику, а не техническое обеспечение. Это формирует бизнес-требования к фреймворку. Они содержат в себе как роутинг, так и шардинг — всё, что нужно, чтобы писать только бизнес-логику.
Проблема в том, что роутинг, валидация и прочие задачи, которые решают распространённые фреймворки — настолько малая часть от требований к фреймворку в рамках хайлоада, что используется он, или не используется — вообще не важно. То есть, преимущества от реализованных классов компенсируются ограничениями фреймворка и быстро растущим оверхедом от всяческих IoC контейнеров.
Проблема в том, что роутинг, валидация и прочие задачи, которые решают распространённые фреймворки — настолько малая часть от требований к фреймворку в рамках хайлоада, что используется он, или не используется — вообще не важно. То есть, преимущества от реализованных классов компенсируются ограничениями фреймворка и быстро растущим оверхедом от всяческих IoC контейнеров.
Наверно особенность в том, что в CodeIgniter вы продолжаете писать на php, а в других фреймворках — на самом фреймворке.
Скорее, нежелание менеджеров снижать темпы и терять время.
Ничего удивительного, очень достойный и простой фрэймворк, именно простота и не завязанность на большом количестве кода и классов дала ему такую популярность. Пишу до сих пор по инерции, так как наработа библиотека уже из более чем несколько десятков классов, свой блог движок, своя cms, свой магазин есть. Простой и стабильный фрэймворк, а по возможностям ничем не уступает мастодонтам.
То же, что ответили в комментах выше. Пишу и продолжаю писать на нем. Есть своя CMS, которую только-что обновил — клиентам нравится. Нет вопросов и требований к хостингам. Главная страница последнего сделанного сайта съедает 1.1 Мб ОЗУ. И… я не инстаграммы с твиттерами пишу, а корпоративные сайты для небольших контор, для которых что нужно? ОРМ? Миграции? Юнит-тесты? Шаблонизаторы? Свое API? Пространства имен? PSR-ы? Да неужели? Если вам дать на доработку проект на CI, вы с ним разберетесь за пару часов, разве нет?
Я сам метался за последний год, попробовал Yii (не хочу, бесит структура, бесят генераторы), Laravel (симпатично, но отложил), Symphony2 и Zend (сложно и долго, надо разбираться и учить матчасть, монстры). И решил, что останусь на CI: для моих задач все есть, баги(фичи) известны, сторонние кодеры легко вникают в структуру моих проектов (написано у меня все аккуратно), летает даже на самых дешевых хостингах, среднестатистический сайт собирается за 1-2 дня.
Надеюсь лишь, что трешка все же выйдет не к 20-му году и все, что мне от нее нужно, это подпилить пару мелочей в текущей 2.1.3.
Я сам метался за последний год, попробовал Yii (не хочу, бесит структура, бесят генераторы), Laravel (симпатично, но отложил), Symphony2 и Zend (сложно и долго, надо разбираться и учить матчасть, монстры). И решил, что останусь на CI: для моих задач все есть, баги(фичи) известны, сторонние кодеры легко вникают в структуру моих проектов (написано у меня все аккуратно), летает даже на самых дешевых хостингах, среднестатистический сайт собирается за 1-2 дня.
Надеюсь лишь, что трешка все же выйдет не к 20-му году и все, что мне от нее нужно, это подпилить пару мелочей в текущей 2.1.3.
Поддерживаю на счет CI. Но я вот лично не жду когда они допилят трешку и юзаю свежайший код из репозитария. Конечно же, на свой страх и риск.
Несколько лет писал на CI. Все плюсы вы перечислили для небольших проектов, полностью с вами согласен. Но когда поглубже разобрался в Yii, теперь только на нем все свои проекты пишу, времени на разработку типовых вещей уходит на порядок меньше, как и на их правки.
Два года уж прошло… Чует моё сердце велосипедисты никуда не делись :-)
Ну хоть yii — первый, а в остальном статистика весьма странная
flourish для элементарных сайтов, F3 для тех, что посложней
В том числе phalcon
Странная тем, что почти половина — это CMS, которые даже если бы и было желание — нельзя назвать фреймворком. Мало того, их и просто допилить нельзя не нарушая целосность системы.
Лучший php-фреймворк — Ruby on Rails
Bitrix — практически для всех конференционных сайтов (РИФ, RIW, i-Comf, и много др)
Yii — для кастомных проектов, например RUNET-ID и часть подсайтов Премии Рунета (пока недоступны публично)
Phalcon — в этом году на нем будет Народное Голосование
Yii — для кастомных проектов, например RUNET-ID и часть подсайтов Премии Рунета (пока недоступны публично)
Phalcon — в этом году на нем будет Народное Голосование
Я очень рад, Yii лидирует :)
limb framework
Добавьте еще Laravel.
Почему такой низкий процент Symfony2? Сложность изучения, или «интерпрайзность»? Вроде с ним в средних проектах может только Yii сравниться, а в крупных — он даже удобнее.
Пользуемся sf1, проект большой, почему мы не на sf2.
А как же Yii2?
ModX
MODX
- MODX для малого и среднего уровня корпоративных сайтов
- Yii — для специализированных проектов
- Bitrix — если очень нужно клиенту :)
ModX
Laravel
modx evolution
MODX
Используем Yii для внутрикорпоративной системы, очень ждем Yii2.
Это не популярность, это плохая документированность.
А если поменять местами?
FuelPHP
Другое: HostCMS
Я лично на своем опыте писал на много чем.
Лично мне, понравились Друпал и Симфони
Drupal — хорошо подходит как CMF (Content Manager Framework)
Symfony 2 — очень сильный монстр, на котором можно написать приложения любой сложности.
Лично мне, понравились Друпал и Симфони
Drupal — хорошо подходит как CMF (Content Manager Framework)
Symfony 2 — очень сильный монстр, на котором можно написать приложения любой сложности.
До сих пор пользуюсь sf 1.4 в своих проектах. Вопрос для людей имеющих опыт с sf 2 — разработка быстрей идет чем на symfony 1?
Использую фреймворк от LiveStreet для разработки различных проектов, от визиток и магазинов, до разнообразных сервисов.
LIMB в проектах на самописной CMS, Bitrix — на всех остальных.
Пробовал разное, но остановился Yii.
Интересно почему Yii любят в основном в России
Скрытый текст
Неправда, на odesk тоже есть куча по нему вакансий, + из стран СНГ большая популярность т.к. сообщество очень дружное русскоговорящее (англоговорящее тоже большее), что впринципе и отражено в core-team составе :)
СНГ. :-) В Украине, Белоруссии и Казахстане тоже очень и очень популярен.
Мне кажется не стоит этим данным доверять. Программисты не ищут yii, ищут yii AR, yii два подключения в проекте и тд
github.com/languages/PHP — вот чему стоит доверять. Правда скорее в плане динамики развития, видно что лидеры «форкинга» — laravel, CI, symfony, zf2
github.com/languages/PHP — вот чему стоит доверять. Правда скорее в плане динамики развития, видно что лидеры «форкинга» — laravel, CI, symfony, zf2
И еще… судя это статистике — www.google.com/trends/explore#cat=0-5-31-733&q=yii%2C%20symfony%2C%20Zend%20Framework%2C%20Kohana%2C%20CodeIngiter&cmpt=q
Только в России фреймворками и пользуются, что пожалуй похоже не бред
Только в России фреймворками и пользуются, что пожалуй похоже не бред
Программисты не ищут yii, ищут yii AR, yii два подключения в проекте и тд
Разумеется в трендах учитываются все поисковые фразу с содержанием этого слова и это легко проверяется.
Yii как основной, сейчас осваиваю Yii2, параллельно поглядываю в сторону Laravel4.
MODX
onPHP
Laravel 4
Уважаю фреймворки (и даже в свое время работал в одной компании использовал Zend) но все-таки свой стиль роднее.
За 10+ лет программирования на php уже создал себе свой стиль которым решаю самые разные задачи (от простых страничек, магазинов и заканчивая играми).
Так и нагрузка минимальная, каждая буковка в коде родная, и ни к чему не нужно подстраиваться.
За 10+ лет программирования на php уже создал себе свой стиль которым решаю самые разные задачи (от простых страничек, магазинов и заканчивая играми).
Так и нагрузка минимальная, каждая буковка в коде родная, и ни к чему не нужно подстраиваться.
Каждый PHP-шник должен написать свой фреймворк, с блэкджеком и шлюхами.
Основная сила фреймворков — это сообщества вокруг них. Сообщество развивает ядро (и вы, как часть сообщества, можете в этом участвовать, а можете и не тратить на это время), за счет сообщества фреймворк обрастает мясом в виде готовых решений на базе него, сообщество коммит баг/секьюрити-фиксы.
Кроме того у фреймворков, как правило, лучше дела с документацией и они регламентируют правила оформления кода.
Все это незаменимо при командной работе над проектом.
Кроме того у фреймворков, как правило, лучше дела с документацией и они регламентируют правила оформления кода.
Все это незаменимо при командной работе над проектом.
Использую FuelPHP Framework.
Обожаю MZZ Framework :) Его постоянно и с большим успехом применяет наша компания. Наверное здесь про него почти никто не знает, но да ладно — каждому свое. Спасибо zerkms и mz за его создание. Минусы есть, естественно, без этого развитие невозможно. Да и жалко, что уже практически не развивается, остались лишь немногие :)
LiMB Framework но помимо него хочу попробовать Phalcon PHP и Yii
А он разве жив?
Да, всё ок github.com/limb-php-framework/limb
MODX EVO
Вот в этом комментарии я говорил про решение на базе MODX EVO с базой больше 100к товаров.
Пока дописываем мануалы и готовим пакет для установки.
Но демосайт уже готов.
почитать что получилось можно тут
поиграться с демосайтом на 128к товаров с фильтрацией сортировками и пагинацией можно тут
Пока дописываем мануалы и готовим пакет для установки.
Но демосайт уже готов.
почитать что получилось можно тут
поиграться с демосайтом на 128к товаров с фильтрацией сортировками и пагинацией можно тут
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Какой PHP-фреймворк вы используете?