Ну вроде все пришли к согласию, что опенсурсные CMS — фигня с точки зрения кода. С точки же зрения бизнеса — it depends. Бывает проще написать с нуля на нормальном фреймворке, бывает выгоднее использовать существующий какашкокод. Все зависит от задач.
Есть также мнение, что при наличии определенных ресурсов почти на любую CMSку можно повесить кучку своих расширений которые создадут приемлемые условия для прикладных задач.
Может, wordpress? В интернетах есть довольно много тем с зашитой функциональностью по показы галерей и видео. Видео вообще можно вставлять из youtube :) Гуглить по wordpress premium theme, wordpress portfolio theme.
В wordpress — нормальный класс DB? Не смешите мои тапочки. Там ни нормальной параметризации запросов, ни обработки исключений нет, надо перед каждым запросом самостоятельно защищаться от SQL Injection, а после запроса проверять не случилось ли чего (кстати, а как вам включенные по умолчанию magic quotes, коверкающие строки?). Хуже только прямая работа через mysql_чтототам. Сравните хотя бы с Doctrine, не говоря о activerecord в rails или hibernate в java.
Огорчу вас, но хуками можно влезть далеко не везде. А архитектура админки ничего кроме слез не вызывает — она просто провоцирует на написание упомянутого мной выше быдлокода а постоянными switch и мешаниной из логики доступа к данным, вывода html и прочего. И большинство разработчиков плагинов этот быдлокод пишут мегабайтами. Единственное что хоть как-то спасает — собственная библиотечка.
Чтобы не производить впечатление тупой ругани — API доступа к страницам, постам и прочим вещам, которые обычно используются в темизации, весьма хорош, тут ничего не скажешь. Есть некоторые несуразности (например, в версии 2.9 умрешь работать с нестандартными таксономиями через родной API), но немного.
Примеры явной дури: попробуйте создать в joomla пользователя или роль без прямой записи в таблицы. Попробуйте поменять страницу логина в wordpress (что, не получается?) Умиляют постоянные проблемы 1000+1 в Drupal… Пойду напишу что-нибудь на рельсах и выпью за здоровье замечательных парней из 37signals.
Ребят, это только я замечаю что у подавляющего большинства опенсурсных PHPшных CMS архитектура ни к черту? Ни тебе ORM, ни нормальной структуризации кода, о возможностях повторного использования логики даже и вспоминать как-то неудобно. А ведь так хотелось бы писать красивый и полезный код, а не долбить чертовы mysql_escape_string перед каждой вставкой в базу и писать столь любимые быдлокодерами switch($action)… для принятия решения какой же кусок кода ответственен за обработку запроса.
Несмотря на всю мою любовь к рельсам, есть у таких штук две серьезные проблемы, а именно хостинг, который не у каждого хостера купишь, и слабое комьюнити, которое выливается в вопрос клиента «а что я буду с этим делать если мы с тобой прекратим работать»?
Плюс, возьмем тот же radiant — там на сколько-нибудь сложном сайте черт ногу сломит в понаписанном в браузере коде.
Повторяя один старый анекдот — «но такая фигня получается...»
Для тех кто не слышал: приходит девушка наниматься на работу, ее спрашивают сколько символов она набирает в минуту. Девушка: две тысячи четыреста (в сторону — «но такая фигня получается...»)
Голосовать не могу, но за статью спасибо!
Но на практике возникает другой вопрос — как лучше поставить процесс разработки UI чтобы удержаться на лезвии ножа «добавили лишнее — не добавили нужного». Для себя пока остановился на необходимости детального прототипирования софта в balsamiq mockups и отыгрывания на прототипе «рабочих» ситуаций, благо там можно кликать по кнопкам с переходами на другой экран.
А еще есть проблема с пониманием важности вопроса клиентом — он-то думает «да ну вас, еще тут время тратить играться с интерфейсами — кодить надо!». Не у всех получается противостоять давлению.
Они конечно тяжеловаты для этого применения, зато весьма дешевы учитывая возраст, и как было сказано выше — очень хорошо повторяют траекторию. Я не знаю как эта модель, а 420-я при номинальной нагрузке 120 килограмм может повторить траекторию с точностью в половину миллиметра. Иногда это выглядит завораживающе — когда робот несется на полной скорости с тяжелой болванкой, а потом плавно и точно останавливает ее в миллиметре от стены. Интересно только, не мешает ли шум — у них шкаф контроллера как хороший комод и прилично шумит вентиляторами. Плюс, при движении привода сильно свистят из — за импульсного управления и щелкают при трогании.
Где-то в интернетах был еще ролик как чуваки на 420-х прицепили кресло с пятиточечным ремнем и устроили покатушки.
Вряд ли пьяных. Некоторые решения тянут просто на архитектурные преступления. Например, дефолтное использование magic quotes вместо того чтобы написать нормальный API для работы с базой и тихонько на него переползать.
Уважаемый, а если нормировать график? То есть считать не абсолютные количества пользователей, а приведенные к цифрам рождаемости по месяцам. Есть у меня мыслишка что график станет практически ровным.
Возможно Вы правы — я не настолько разбираюсь в вопросе. Правда мне кажется что лучше пусть резонансная частота ползет вверх чем получить КЗ. Но это имхо.
Очень похоже на сказку, потому что длина волны на басах в разы больше размера колонки и положение элементов не должно ни на что особо влиять. Но в спор вступать не буду.
В данном случае дырка сзади фазоинвертором не является — ее диаметр намного больше длины, это определяющий критерий :) К сожалению… А насчет положения фазоинвертора было много споров, и нередко его делают прямо около басового динамика, причем на дорогой акустике (Bose, JBL, B&W). Назад же чаще выносят на дешевой, честно говоря не знаю почему.
Есть также мнение, что при наличии определенных ресурсов почти на любую CMSку можно повесить кучку своих расширений которые создадут приемлемые условия для прикладных задач.
Огорчу вас, но хуками можно влезть далеко не везде. А архитектура админки ничего кроме слез не вызывает — она просто провоцирует на написание упомянутого мной выше быдлокода а постоянными switch и мешаниной из логики доступа к данным, вывода html и прочего. И большинство разработчиков плагинов этот быдлокод пишут мегабайтами. Единственное что хоть как-то спасает — собственная библиотечка.
Чтобы не производить впечатление тупой ругани — API доступа к страницам, постам и прочим вещам, которые обычно используются в темизации, весьма хорош, тут ничего не скажешь. Есть некоторые несуразности (например, в версии 2.9 умрешь работать с нестандартными таксономиями через родной API), но немного.
Плюс, возьмем тот же radiant — там на сколько-нибудь сложном сайте черт ногу сломит в понаписанном в браузере коде.
Для тех кто не слышал: приходит девушка наниматься на работу, ее спрашивают сколько символов она набирает в минуту. Девушка: две тысячи четыреста (в сторону — «но такая фигня получается...»)
Но на практике возникает другой вопрос — как лучше поставить процесс разработки UI чтобы удержаться на лезвии ножа «добавили лишнее — не добавили нужного». Для себя пока остановился на необходимости детального прототипирования софта в balsamiq mockups и отыгрывания на прототипе «рабочих» ситуаций, благо там можно кликать по кнопкам с переходами на другой экран.
А еще есть проблема с пониманием важности вопроса клиентом — он-то думает «да ну вас, еще тут время тратить играться с интерфейсами — кодить надо!». Не у всех получается противостоять давлению.
Где-то в интернетах был еще ролик как чуваки на 420-х прицепили кресло с пятиточечным ремнем и устроили покатушки.