Comments 168
Мне кажется эти два подхода будут отличаться размером команды. В случае если отказаться от использования готовой CMS, потребуется гораздо больше человеческих ресурсов. И есть вероятность что придется изобретать велосипед, хотя этот велосипед вполне можно сделать с блекджеком.
Для визитки, велосипед? :)
Смотря что понимать визиткой. Если одна-три страницы типа «Привет всем это Федя! Я занимаюсь прослушиванием любимой музыки. У меня есть классные фотки, расположенные в хранилеще по ссылке.» — тогда весь велосипед лежит в области голого html, тут изобретать практически нечего. А вот если ближе к классике — лента новостей (а то и несколько), фотоальбом, и пр… Да, это все можно сделать, можно написать все с нуля, но требуется время, которого, как обычно, сильно нехватает.
Кстати, мне кажется что все-таки автор не совсем прав — у CMS своя ниша, расчитанная на такие сайты-визитки (плюс, если хорошо проработана архитектура, то в некоторых случаях может сойти и за некое подобие фреймворка). Если нужно большее — нужно использовать фреймворки. Которые, конечно же, опять-таки можно и с нуля изобрести, но опять-таки — на это требуется время, которого, при работе обычной команды в обычном проекте, катострофически не хватает.
Кстати, мне кажется что все-таки автор не совсем прав — у CMS своя ниша, расчитанная на такие сайты-визитки (плюс, если хорошо проработана архитектура, то в некоторых случаях может сойти и за некое подобие фреймворка). Если нужно большее — нужно использовать фреймворки. Которые, конечно же, опять-таки можно и с нуля изобрести, но опять-таки — на это требуется время, которого, при работе обычной команды в обычном проекте, катострофически не хватает.
Мне кажется автор именно фреймворки и описал. Или мне кажется?
Не похоже… Нормально спроектированый фреймворк предоставляет архитектуру, базовую модель взаимодействия компонентов системы. Ну и сами базовые компоненты с интерфейсами конечно тоже. Но те минусы, которые автор перечислил ну никак не вяжутся с фреймворками. Но зато автор преподнес хороший ход мыслей на тему «как веб-разработчик вырастает из cms и дорастает до фремворков». Осталось посмотреть какие фремворки есть, и, может быть, набраться еще у них опыта.
А при чём тут команда? Если говорить о простых шаблонных решениях, которые хорошо ложатся на определённую CMS, с которой вы хорошо знакомы, и не требуется высокая производительность и масштабируемость, да, это будет быстрый и малозатратный способ, и писать что-то кастомное нет смысла. И таких случаев конечно немало.
Но там где надо шагнуть за эти рамки, вопрос трудоёмкости того или иного решения становится уже весьма спорным, т.к. придётся не написать такую же CMS а только необходимый для проекта функционал. И при увеличении сложности, часто возникает ситуация, когда написать/переделать кода для добавления той или иной функции, в том виде, в котором нужно, при использовании готовой CMS придётся значительно больше, чем при реализации с нуля.
Плюс проблемы с быстродействием и масштабируемостью в случае в случае универсальных CMS.
И такая ситуация может возникать задолго до того, как сайту понадобится комманда для разработки. И разработка приложения под конкретные требования на фреймворке, может как раз отсрочить этот момент.
И при чём тут «изобретение велосипеда» — если нет какого-то специализированного инструмента для конкретного проекта, бывает, что его имеет смысл создать, вместо использования менее подходящего инструмента «для всего».
Но там где надо шагнуть за эти рамки, вопрос трудоёмкости того или иного решения становится уже весьма спорным, т.к. придётся не написать такую же CMS а только необходимый для проекта функционал. И при увеличении сложности, часто возникает ситуация, когда написать/переделать кода для добавления той или иной функции, в том виде, в котором нужно, при использовании готовой CMS придётся значительно больше, чем при реализации с нуля.
Плюс проблемы с быстродействием и масштабируемостью в случае в случае универсальных CMS.
И такая ситуация может возникать задолго до того, как сайту понадобится комманда для разработки. И разработка приложения под конкретные требования на фреймворке, может как раз отсрочить этот момент.
И при чём тут «изобретение велосипеда» — если нет какого-то специализированного инструмента для конкретного проекта, бывает, что его имеет смысл создать, вместо использования менее подходящего инструмента «для всего».
UFO just landed and posted this here
Не существует ни одной задачи, которую нельзя решить при помощи Битрикса.
Гугл хочу! Сделаете?
Я так понимаю про Битрикс — это был тонкий сарказм?
А насчет невозможно — я и не говорил, что невозможно. Я говорил о том, что при отказе от CMS возможностей для более гибкого построения архитектуры больше.
И да, если вы изначально заложили плохую архитектуру — то сами себе злобный Буратино.
Ответственности в данном случае ГОРАЗДО больше. И ее конечно же нужно осознавать.
А насчет невозможно — я и не говорил, что невозможно. Я говорил о том, что при отказе от CMS возможностей для более гибкого построения архитектуры больше.
И да, если вы изначально заложили плохую архитектуру — то сами себе злобный Буратино.
Ответственности в данном случае ГОРАЗДО больше. И ее конечно же нужно осознавать.
не существует ни одной задачи которую нельзя решить с помощью ассемблера
UFO just landed and posted this here
По поводу сертификации — сертификат это просто дополнение к тому опыту и знаниям которые есть у человека. Я знаю достаточно разработчиков у которых нет ни одного сертификата — но они отличные специалисты и профессионалы в своем деле. И знаю несколько людей с сертификатами которые в общем-то кроме сертификатов ничего и не могут предъявить ни клиенту, ни работодателю.
Сертификат стоит брать во внимание, но не стоит делать из него культ.
Так сертификат по Битриксу значит только то что человек знает Биртикс (а иногда не значит и этого).
По поводу низкой квалификации — действительно имея большую свободу и мало знаний можно наломать дров. Это не минус подхода. Это значит только то что человеку нужно больше практиковаться и наращивать свой уровень. А если он все время будет сидеть в CMS-ке — вряд ли он когда-то чему-то научится. Во всяком случае вероятность гораздо меньше.
«Отсутствие понятий документ, права доступа, шаблоны» — а вы уверенны что эти понятия должны быть? Архитектура на основе предметной области предполагает как раз то, что разработчик оперирует именно объектами предметной области, а объектами навязанными ему CMS-кой.
«Сложно передать разработку другой команде, низкое качество документации» — использование CMS разе подразумевает что документация в проекте будет вестись идеально?! Нет, ну если считать конечно за документацию инструкцию к CMS, то да. Но проект документация которого ограничивается инструкцией к CMS по всей видимости не подпадает под те критерии которые я назвал в начале статьи.
«Сложно передать разработку другой команде» — опять же, это не проблема архитектуры, это проблема того насколько качественно пишется код.
Иными словами — те минусы что вы привели, относятся не к архитектуре а больше к команде и ее стилю работы. Но поверьте. Если у вас все сотрудники — люди которые выучились по книгам для чайников, и нет своей документации — никакая CMS вас не спасет.
Сертификат стоит брать во внимание, но не стоит делать из него культ.
Так сертификат по Битриксу значит только то что человек знает Биртикс (а иногда не значит и этого).
По поводу низкой квалификации — действительно имея большую свободу и мало знаний можно наломать дров. Это не минус подхода. Это значит только то что человеку нужно больше практиковаться и наращивать свой уровень. А если он все время будет сидеть в CMS-ке — вряд ли он когда-то чему-то научится. Во всяком случае вероятность гораздо меньше.
«Отсутствие понятий документ, права доступа, шаблоны» — а вы уверенны что эти понятия должны быть? Архитектура на основе предметной области предполагает как раз то, что разработчик оперирует именно объектами предметной области, а объектами навязанными ему CMS-кой.
«Сложно передать разработку другой команде, низкое качество документации» — использование CMS разе подразумевает что документация в проекте будет вестись идеально?! Нет, ну если считать конечно за документацию инструкцию к CMS, то да. Но проект документация которого ограничивается инструкцией к CMS по всей видимости не подпадает под те критерии которые я назвал в начале статьи.
«Сложно передать разработку другой команде» — опять же, это не проблема архитектуры, это проблема того насколько качественно пишется код.
Иными словами — те минусы что вы привели, относятся не к архитектуре а больше к команде и ее стилю работы. Но поверьте. Если у вас все сотрудники — люди которые выучились по книгам для чайников, и нет своей документации — никакая CMS вас не спасет.
1) Зря вы так – «php для чайников» никогда не повысит квалификацию разработчика до уровня написания хорошего веб-приложения, которым кто-то будет пользоваться.
2) Лучше свой велосипед, чем неповоротливое и тяжелое приложение.
3) Как и писал автор, в CMS, как правило, отсутствует необходимая для приложения (заметьте, не для сайта, а для веб-приложения) логика, которую в итоге все равно приходится разрабатывать самим, так что такой код передать другой команде в итоге будет еще сложнее. К тому же, при разработке пишется документация на API, структуру и тд., так что с документацией вопрос необходимо решать еще перед началом разработки.
4) А где вы видели качественные веб-приложения с низкой стоимостью разработки (если не вы сами разрабатываете их для себя)?
2) Лучше свой велосипед, чем неповоротливое и тяжелое приложение.
3) Как и писал автор, в CMS, как правило, отсутствует необходимая для приложения (заметьте, не для сайта, а для веб-приложения) логика, которую в итоге все равно приходится разрабатывать самим, так что такой код передать другой команде в итоге будет еще сложнее. К тому же, при разработке пишется документация на API, структуру и тд., так что с документацией вопрос необходимо решать еще перед началом разработки.
4) А где вы видели качественные веб-приложения с низкой стоимостью разработки (если не вы сами разрабатываете их для себя)?
полностью не согласен.
во-первых, для любого сайта нужна верстка. эту верстку необходимо натянуть на саму cms.
во-вторых, если это asp.net mvc, то существует такая штука как MvcScaffolding, благодаря ей происходит автоматическая генерация многих страниц с CRUD-функционалом для админ-панели. про DynamicData автор уже упомянул.
в-третьих, при использовании DDD, можно разбить программу на несколько малосвязных слоев, что только повышает дальнейшее сопровождение кода (UI, Domain, Business).
а правильное использование паттернов при проектировании только облегчает работу.
во-первых, для любого сайта нужна верстка. эту верстку необходимо натянуть на саму cms.
во-вторых, если это asp.net mvc, то существует такая штука как MvcScaffolding, благодаря ей происходит автоматическая генерация многих страниц с CRUD-функционалом для админ-панели. про DynamicData автор уже упомянул.
в-третьих, при использовании DDD, можно разбить программу на несколько малосвязных слоев, что только повышает дальнейшее сопровождение кода (UI, Domain, Business).
а правильное использование паттернов при проектировании только облегчает работу.
np-полные:)
У меня есть каталог товаров. Но фишка в том, что он формируется из трех источников — каталогов с других сайтов (т.е. 3 сайта источника каталогов). Два из этих каталогов это каталоги одежды, третий — и одежды, и разных других товаров (компы, телефоны, даже мотоциклы). Т.е. в одном разделе каталога товары одного типа, в другом набор характеристик товара уже совершенно другой. Что, городить на каждый тип свой инфоблок?
А еще нужно автоматически периодически парсить эти каталоги, актуализировать каталоги внутри битрикса. Так же должен быть механизм который позволял бы делать привязку разделов каталога на сайте к разделам в этих каталогах-источниках. А еще нужно точно знать из какого каталога-источника был добавлен товар, т.к. формирование цены зависит от источника не говоря уже о том, что товарные номенклатуры в каталогах-источниках могут пересекаться.
Как, битрикс из коробки может такое?
А еще нужно автоматически периодически парсить эти каталоги, актуализировать каталоги внутри битрикса. Так же должен быть механизм который позволял бы делать привязку разделов каталога на сайте к разделам в этих каталогах-источниках. А еще нужно точно знать из какого каталога-источника был добавлен товар, т.к. формирование цены зависит от источника не говоря уже о том, что товарные номенклатуры в каталогах-источниках могут пересекаться.
Как, битрикс из коробки может такое?
Битрикс как 1С — из коробки ничего не может, но тысячи допильщиков на сумму превышающую стоимость коробки вам его допилят :) Или не допилят. Тут уж как повезет — их же тысячи :)))
Безусловно допилят. Но тогда возникает резонный вопрос, нафига с этой цепочке битрикс. Что и подтверждает тезис автора. Пусть уж сразу пилят по требуемую задачу.
UFO just landed and posted this here
А можно привести примеры из личной практики проектов выполненных на данной системе? Чисто словесное описание, в духе, какая была задача, за какое время выполнена, сколько пришлось и пришлось ли писать самостоятельно?
И если разработчики обучались программированию под Битрикс, то это единый интерфейс, одна легкопортируемая база, стиль кодирования и другие автоматические плюшки.Вам не приходила идея, что в этой фразе слово «битрикс» можно заменить на любой %framework_name%? Какая разница на чем писать? Если в проекте есть документация и требования к стандартам кодирования и адекватная команда, они напишут на всем. Ну разве что на битриксе не напишут, потому что с этим говном разбираться — себя не уважать.
хм, разве у битрикса есть свой code-style??
Я смотрел исходники модулей, это тихий ужас! Смешанный ООП и функциональный подход, порой совсем не логичные блоки кода ну т.д. и т.п.
Что о самой CMS, то она выгодна лишь разработчикам, которые за ее допиливание будут получать деньги… иногда даже много денег. Для заказчика же битрикс станет довольно дорогим удовольствием.
Я смотрел исходники модулей, это тихий ужас! Смешанный ООП и функциональный подход, порой совсем не логичные блоки кода ну т.д. и т.п.
Что о самой CMS, то она выгодна лишь разработчикам, которые за ее допиливание будут получать деньги… иногда даже много денег. Для заказчика же битрикс станет довольно дорогим удовольствием.
Проще написать модуль импорта, который будет все это учитывать, чем делать то же самое + функционал магазина.
Для программиста, кстати, задача раз плюнуть. Много работы для администратора/копирайтера, что бы совместить категории и параметры, но чем поможет самописный движок?
Для программиста, кстати, задача раз плюнуть. Много работы для администратора/копирайтера, что бы совместить категории и параметры, но чем поможет самописный движок?
Раз плюнуть говорите? Хм…
Возьметесь, а? В какой срок и почем?
P.S. Я, кстати, не говорю, что задача не реализуема, вопрос, какими силами.
Возьметесь, а? В какой срок и почем?
P.S. Я, кстати, не говорю, что задача не реализуема, вопрос, какими силами.
Движок любой или только Битрикс?
Сделать автоматический импорт, совместив параметры и категории по таблицам вида:
«название параметра в магазине1» => «id параметра в нашем магазине»
«название значения параметра в магазине1» => «id значения параметра в нашем магазине»
Ну и тоже по категориям. И по совпадающим товарам.
Задача такая? Неделя с запасом + что бы кто-то более низкооплачиваемый это все совместил, это уже зависит от количества товаров.
Времени особо нет, но если будет заманчивая цена, то всегда можно найти.
Сделать автоматический импорт, совместив параметры и категории по таблицам вида:
«название параметра в магазине1» => «id параметра в нашем магазине»
«название значения параметра в магазине1» => «id значения параметра в нашем магазине»
Ну и тоже по категориям. И по совпадающим товарам.
Задача такая? Неделя с запасом + что бы кто-то более низкооплачиваемый это все совместил, это уже зависит от количества товаров.
Времени особо нет, но если будет заманчивая цена, то всегда можно найти.
Ну и что значит какими силами? Это не менюшечку сделать, понятно, хотя и ничего сверхъестественного.
Вопрос в другом: что конкретно здесь усложняет наличие CMS?
Вопрос в другом: что конкретно здесь усложняет наличие CMS?
Усложняет тем, что из коробки указанного функционала нет и нужно пилить свой велосипед буду зажатым в рамки платформы.
Это вечный выбор — использовать чужие наработки будучи зажатым в их рамки или писать всё самому. Используя PHP мы зажаты в его рамки (например отсутствие true FastCGI «из коробки»), используя фреймворк или CMS мы зажаты в рамки его архитектуры. Нужно оценивать что выгоднее — чужой код или гибкость — в каждом конкретном случае. И не бояться сменить решение в случае если начальное оказалось ошибочным или требования качественно изменились.
Как показывает практика в чистом PHP мы безусловно зажаты в определенные рамки. Но это справедливо вообще для всего в жизни. Другой вопрос в степени этой зажатости. На чистом пхп оперативный просто шире.
Хотя для начинающего разработчика зажатость полезна, она не дает ему свалиться ввиду отсутствия опыта в дикий говнокод. К сожалению я пока не вижу среди массовых систем ни одну, которая позволяла бы его правильно зажать и не потерять при этом на производительности этого разработчика. Не говоря уже об уровне изоляции которая не позволяла бы свалить систему в целом, а не только его кусок кода.
Хотя для начинающего разработчика зажатость полезна, она не дает ему свалиться ввиду отсутствия опыта в дикий говнокод. К сожалению я пока не вижу среди массовых систем ни одну, которая позволяла бы его правильно зажать и не потерять при этом на производительности этого разработчика. Не говоря уже об уровне изоляции которая не позволяла бы свалить систему в целом, а не только его кусок кода.
Это понятно, что чем выше уровень абстракции, тем больше зажатость. Ассемблер предоставляет куда большую гибкость, чем PHP. Правда и он зажат в рамках архитектуры процессора.
По-моему, выбирая что использовать нужно прежде всего оценивать соответствие предметной области задачи и предполагаемого инструмента. Если инструмент допускает простое описание и оперирование терминами предметной области, то он подходит больше чем инструмент этого не допускающий. Если задача формируется в терминах «сайт», «страница сайта», «статья», «пост» и т. п., которые вписаны в CMS, то надо использовать её. Если в терминах «магазин», «товар», «цена», то надо использовать или специализированный инструмент или общий, более низкого уровня абстракции, не заставляющий загонять товар в рамки страницы с описанием товара.
Сложность представляют не предельные случаи, а случаи вроде «на сайте должен быть магазин и набор страниц с товаром», если в терминах предметной области связь выражается легко, но вот в рамках инструмента приходится представлять сущности одного типа через другой. То есть при выборе инструмента нужно определиться какая часть предметной области нам важнее и ориентироваться на неё, не забывая о сложности выражения других частей в терминах основной.
По-моему, выбирая что использовать нужно прежде всего оценивать соответствие предметной области задачи и предполагаемого инструмента. Если инструмент допускает простое описание и оперирование терминами предметной области, то он подходит больше чем инструмент этого не допускающий. Если задача формируется в терминах «сайт», «страница сайта», «статья», «пост» и т. п., которые вписаны в CMS, то надо использовать её. Если в терминах «магазин», «товар», «цена», то надо использовать или специализированный инструмент или общий, более низкого уровня абстракции, не заставляющий загонять товар в рамки страницы с описанием товара.
Сложность представляют не предельные случаи, а случаи вроде «на сайте должен быть магазин и набор страниц с товаром», если в терминах предметной области связь выражается легко, но вот в рамках инструмента приходится представлять сущности одного типа через другой. То есть при выборе инструмента нужно определиться какая часть предметной области нам важнее и ориентироваться на неё, не забывая о сложности выражения других частей в терминах основной.
Web-приложение на ассемблере нельзя назвать гибким
Почему нельзя? Всё что угодно можно реализовать (в рамках архитектуры процессора).
В плане написания и поддержки кода, попросту изврат :)
Все, что Вы пишите на высокоуровневых языках и интерпретируемых и компилируемых, так или иначе отображается в машинный код, а значит — может быть представлено на асме. Но некоторые задачи, вопреки распространенному мнению, не так уж и сложно писать на асме, ведь там есть макросы, библиотеки, да и отдельные инструкции современных процессоров делают больше, чем многие некоторые процедуры из библиотек высокоуровневых языков. Прикладное программирование на асме — конечно очень усложнено, формы на нем не пишут, но вот матмодель обсчитывать иногда проще, чем на высокоуровневых.
UFO just landed and posted this here
UFO just landed and posted this here
Я понимаю как работает PHP и Битрикс. Но где там кнопка «сделать мне сайт»?!
Отличная страница с отличным битриксовым функционалом:
1. Список проектов по 3 в ряд. В последнем ряду почему то только 2. Одна позиция не занята — дырка. В пейджере ещё полно страниц. Почему дырка?
2. Выбираем фильтр, например «И-магаз». После этого ходим по страницам. На первой странице показано «1 — 45» проектов; на второй «46-72», потом «73-99», дальше «100-126». Почему на каждой странице рандомное количество элементов? Магия битрикса?
Этому шаманству обучают на курсах по Битриксу? Потом битриксойды получают сертификаты: шаман N-ой категории?
1. Список проектов по 3 в ряд. В последнем ряду почему то только 2. Одна позиция не занята — дырка. В пейджере ещё полно страниц. Почему дырка?
2. Выбираем фильтр, например «И-магаз». После этого ходим по страницам. На первой странице показано «1 — 45» проектов; на второй «46-72», потом «73-99», дальше «100-126». Почему на каждой странице рандомное количество элементов? Магия битрикса?
Этому шаманству обучают на курсах по Битриксу? Потом битриксойды получают сертификаты: шаман N-ой категории?
Жесть))) Наверное там не постраничная навигация, а просто костыль с ссылками на другие страницы. И в зависимости от важности клиента его перемещают по страницам, вместо того чтобы сделать поле «важности» в БД и сортировать по нему.
Сразу представляю как кто-то прое… лся с Битриксом пол дня и в конце концов родил такой вариант.
Сразу представляю как кто-то прое… лся с Битриксом пол дня и в конце концов родил такой вариант.
Мне хватило посмотреть код файла установки, чтобы понять, почему не стоит использовать Битрикс.
Такой тонкий троллинг?
Пусть сначала Битрикс сделает на своем офф.сайте нормальную возможность отписки от их рекламной рассылки. А то если забыл пароль, то отписаться от надоедливой рекламы просто нереально.
Я бы еще добавил в недостатки CMS
— Открытый код
— Повышенный интерес для взломщиков
Поясню. Повышенный интерес вызывают именно распространенные CMS, так как найдя дырку в каком-то распространенном движке можно одним махом заразить тысячи сайтов. Нет смысла ковырять непопулярную CMS — эффект будет куда меньше. Всему этому способствует второй недостаток — открытый код. Зачастую можно определить версию используемой CMS и ковырять уже не черный ящик, как в случае с самописом, а анализировать исходники. От всего этого можно защититься своевременными обновлениями, но не все эти обновления устанавливают. Часто ждут, пока жаренный петух не клюнет.
Еще один вытекающий из вышесказанного момент — при модификации распространенной системы в ней остаются ее родные дырки, она все так же интересна для взлома и уязвима из-за открытости кода, но обновления уже могут не устанавливаться как раз из-за модификаций. Эта ситуация, на мой взгляд, самая опасная и самая неприятная. Дырки есть и их могут найти, но ты не можешь их легко устранить обновлением.
— Открытый код
— Повышенный интерес для взломщиков
Поясню. Повышенный интерес вызывают именно распространенные CMS, так как найдя дырку в каком-то распространенном движке можно одним махом заразить тысячи сайтов. Нет смысла ковырять непопулярную CMS — эффект будет куда меньше. Всему этому способствует второй недостаток — открытый код. Зачастую можно определить версию используемой CMS и ковырять уже не черный ящик, как в случае с самописом, а анализировать исходники. От всего этого можно защититься своевременными обновлениями, но не все эти обновления устанавливают. Часто ждут, пока жаренный петух не клюнет.
Еще один вытекающий из вышесказанного момент — при модификации распространенной системы в ней остаются ее родные дырки, она все так же интересна для взлома и уязвима из-за открытости кода, но обновления уже могут не устанавливаться как раз из-за модификаций. Эта ситуация, на мой взгляд, самая опасная и самая неприятная. Дырки есть и их могут найти, но ты не можешь их легко устранить обновлением.
Что? С каких это пор открытость исходников была недостатком? И когда это закрытость кого-то останавливала? Не порите чушь, ладно?
С каких это пор открытость исходников была недостатком?
С тех пор, как анализировать исходные коды стало проще, чем изучать черный ящик. Т.е. всегда.
И когда это закрытость кого-то останавливала?
Ответ выше.
Не порите чушь, ладно?
Только после вас.
С тех пор, как анализировать исходные коды стало проще, чем изучать черный ящик. Т.е. всегда.
И когда это закрытость кого-то останавливала?
Ответ выше.
Не порите чушь, ладно?
Только после вас.
Открытость исходных кодов является преимуществом именно потому, что можно проанализировать и исправить, ошибки находятся и исправляются быстрее. И ещё раз скажу: закрытость никого никогда не останавливала, а security by obscurity (в том числе и by source code being closed) не является мерой безопасности вообще, и просто не работает.
Открытость исходных кодов является преимуществом именно потому, что можно проанализировать и исправить, ошибки находятся и исправляются быстрее.
Я с этим не спорю. Сообщество может оказывать поддержку, анализировать, исправлять. Это отлично. Но это с одной стороны. А с другой стороны — анализировать могут не только доброжелатели. Я бы даже больше сказал — у недоброжелателей для анализа больше причин, они заинтересованы в поиске дыр. А мотивация у остальных будет поменьше. Это имхо.
И ещё раз скажу: закрытость никого никогда не останавливала
Я с этим не согласен. Когда дело касается десктопных приложений, например — там дело обстоит немного иначе. Там хочешь не хочешь, а исполняемый код все равно на руках у злоумышленника и он все равно сможет его анализировать. Не так легко, как исходники, но все равно сможет.
Когда же речь идет о веб сервисе — у злоумышленника не будет кода вообще никакого, либо будут исходники. Варианты с кодированием скриптов где-то посередине. Там может сломают, может нет. А когда исходников нет вообще — движок уникальный и как он работает не знает никто снаружи вообще, то никаких данных для анализа кроме внешних реакций просто нет. Вот это будет в самом деле черный ящик.
Так что здесь, имхо, с одной стороны нельзя приравнивать десктопные приложения и веб, а еще — для десктопа это работает слабо, а для веба — очень даже не плохо.
Давайте попробуем вести диалог конструктивно. Обойдемся без безапеляционных утверждений и попробуем оперировать аргументами.
Вы не совсем корректно выразились.
Сам по себе закрытый код выигрыша не дает.
Пример: Фирма толкает CMS с зашифрованными исходниками. Тут находят баг. Вы как администратор не можете оперативно его исправить, так как доступа к исходному коду у вас нет.
Так что закрытый код закрытому рознь.
Сам по себе закрытый код выигрыша не дает.
Пример: Фирма толкает CMS с зашифрованными исходниками. Тут находят баг. Вы как администратор не можете оперативно его исправить, так как доступа к исходному коду у вас нет.
Так что закрытый код закрытому рознь.
История показывает, что черные ящики вскрываются так же легко, а вот проследить за фиксами ошибок намного сложнее.
> ошибки находятся и исправляются быстрее
Ошибки находятся и используются быстрее:-)
Ошибки находятся и используются быстрее:-)
Это не недостаток, просто мысль неправильно сформулирована.
Можно оценивать проект по качеству кода — безусловно у проектов с открытым исходным кодом оно выше.
Можно оценивать проект по ИБ — здесь, с точностью до наоборот.
Если у злоумышленника есть исходные коды проекта, то ему гораздо проще обнаружить уязвимости,
нежели заниматься pen-тестингом.
Можно оценивать проект по качеству кода — безусловно у проектов с открытым исходным кодом оно выше.
Можно оценивать проект по ИБ — здесь, с точностью до наоборот.
Если у злоумышленника есть исходные коды проекта, то ему гораздо проще обнаружить уязвимости,
нежели заниматься pen-тестингом.
Человек прав, зачем минусуете?
Сайты на популярных движках подвержены случайному взлому. Для спама, фишинга, DDOS, ets.
Если сайт никому не нужен, то на дырявом Кастоме он в большей безопасности, чем на популярном движке с одной не очевидной уязвимостью.
Понятно, что если у вас популярный ресурс, который сам по себе представляет интерес для взломщиков, то тут другое уравнение, хотя этот факт и здесь, нельзя игнорировать.
Сайты на популярных движках подвержены случайному взлому. Для спама, фишинга, DDOS, ets.
Если сайт никому не нужен, то на дырявом Кастоме он в большей безопасности, чем на популярном движке с одной не очевидной уязвимостью.
Понятно, что если у вас популярный ресурс, который сам по себе представляет интерес для взломщиков, то тут другое уравнение, хотя этот факт и здесь, нельзя игнорировать.
UFO just landed and posted this here
Я думаю, ботов, которые ищут конкретные уязвимости в конкретных CMS на порядок больше, чем тех, которые используют какие-то алгоритмы для автоматического поиска дыр в неизвестном движке. Вы считаете это не так?
С точки зрения теории вероятности — они либо будут взломаны, либо нет. Одинаковая вероятность.
Вероятность встретить динозавра — 50%. Или встретишь, или не встретишь.
Вероятность встретить динозавра — 50%. Или встретишь, или не встретишь.
Это хабр. Тервер здесь не работает.
habrahabr.ru/blogs/development/128279/#comment_4240143
habrahabr.ru/blogs/development/128279/#comment_4240143
Вероятность привлечь внимание серьезного взломщика, а не скрипт-кидди с эксплоитом, слитого с форума, намного меньше.
Неуловимы Джо такой неуловимый.
Если нормально поддерживать проекты на открытой cms, то шанс взлома будет меньше, чем на закрытой и протестированной 3 калеками.
Если нормально поддерживать проекты на открытой cms, то шанс взлома будет меньше, чем на закрытой и протестированной 3 калеками.
Если закрыты простейшие косяки, то нет. Дыр в открытом продукте может быть на порядок меньше, но найти их через исходники намного проще, чем долбить опытным путем, оставляя следы в логах (пусть не своего ip но попыток взлома).
В крупных открытых проектах такие косяки очень быстро фиксятся, а в закрытых остаются незамеченными.
+ провести ревью кода и найти ошибки не легче, чем «долбить опытным путем».
+ провести ревью кода и найти ошибки не легче, чем «долбить опытным путем».
Имея на руках исходники, можно даже на локалхосте долбить, существенно быстрее и не оставляя следов. Так, что уже этим проще работать с опенсорсом. А ошибки… они часто возникают в самых неожиданных местах, сообщество бывает не успевает реагировать, а на правильном форуме уже лежат эксплоиты. Просто потому что мысль о том, что в таком-то месте может быть дыра, пришла в голову не тому человеку.
Коллективный разум ведь не только на безопасность работает, в данном случае, но и против.
Коллективный разум ведь не только на безопасность работает, в данном случае, но и против.
На локалхосте будет проблематично повторить все версии по и модули cms'ки.
И никто не мешает развернуть(если платная — и купить) закрытую, если это настолько нужно.
И никто не мешает развернуть(если платная — и купить) закрытую, если это настолько нужно.
Если ищем баг в ядре, то достаточно версии, а не списка модулей. А закрытая CMS в данном случае, мало отличается от открытой. Ну да, нет исходников, но тот факт, что любой желающий может развернуть себе копию для экспериментов (и получать нужную информацию через отладчик) и то, что таких желающих будет много (в случае популярной CMS) уже серьезно увеличивает шанс нахождения дыры.
Ничего не увеличит. Если взлом будет так сильно нужен, что будет проводиться ревью кода и стресс тестирование на системе с идентичными версиями по, то хоть закрытая, хоть открытая — всё-равно найдут как взломать, даже через другие части системы.
Но крутиться ли что-то настолько важное на cms'ках?
Но крутиться ли что-то настолько важное на cms'ках?
Увеличит по сравнению с толковым самописом. Не имея возможности развернуть свою копию системы, анализировать уязвимости гораздо сложнее. Особенно, если сервер небыстрый и на той стороне смотрят на появлением в логах подозрительной активности.
А на cms много чего крутится. Может крутиться блог или форум, через который зальют шелл и пойдут дальше на сервера, к которым нет доступа извне. Так было с Бигмиром, который вскрыли через phpbb и залезли на сервера ICQ, нагенерив кучу аккаунтов и слив пароли текущих юзеров.
А на cms много чего крутится. Может крутиться блог или форум, через который зальют шелл и пойдут дальше на сервера, к которым нет доступа извне. Так было с Бигмиром, который вскрыли через phpbb и залезли на сервера ICQ, нагенерив кучу аккаунтов и слив пароли текущих юзеров.
Вы хоть раз занимались поиском уязвимостей? Не пишите бред, досконально изучить исходники намного сложнее. Даже сами авторы больших продуктов не представляют на 100% что творится, иначе не было бы дыр.
Поиск уязвимостей всегда ведется через черный ящик.
Поиск уязвимостей всегда ведется через черный ящик.
Занимался поиском.
Когда я заводил локальную копию CMS на которой работал сайт, где искались дырки, я проанализировал стандартным софтом для поиска уязвимостей (который пропарсив тысяч 10 страниц, или точнее, вариантов страниц с разными параметрами), нашем мне все формы, куда можно загружать файлы. Таких оказалось 10, пару из который я бы и за год не нашел (ссылки были очень незаметными и поле с заливкой появлялось уже после отправки одной post формы).
Я посмотрел все формы, нашел такую, куда заливалась картинка и можно потом было получить ее копию до байта (т.е. картинка проверялась, но не изменялась). Полез в исходник, нашел место, где проверялась картинка. Оказывается, туда можно было приложить не только картинку, но и архив и еще несколько видов файлов, потому проверка шла просто по расширению файла (в других местах вызывались функции работы с картинками и проверялось содержимое). Веб-сервер был настроен так, что если даже залить скрипт под расширением jpg, то исполнен он не будет.
Но заметил, что в исходнике использовалась фукнция, которая имела ограничение на длину файла. В итоге создав файлик shell___ (точно не помню сколько подчеркиваний)_.jpg.php, я добился того, что функция увидела все включая .jpg, но не дальше. А веб-сервер видел полный путь, собственно, залив такой файлик я сразу получил шелл.
А сколько бы я долбался с сайтом на шареде, чтобы найти все формы (оставляя следы в логах), потом прикидывая варианты, как туда залить шелл (о том, как именно проверялось имя файла я ж не знал, а стандартная фукнция в актуальной на тот момент версии php работала корректно, отличие от версии из какой-то популярной но сторонней библиотеки (вроде PEAR).
Когда я заводил локальную копию CMS на которой работал сайт, где искались дырки, я проанализировал стандартным софтом для поиска уязвимостей (который пропарсив тысяч 10 страниц, или точнее, вариантов страниц с разными параметрами), нашем мне все формы, куда можно загружать файлы. Таких оказалось 10, пару из который я бы и за год не нашел (ссылки были очень незаметными и поле с заливкой появлялось уже после отправки одной post формы).
Я посмотрел все формы, нашел такую, куда заливалась картинка и можно потом было получить ее копию до байта (т.е. картинка проверялась, но не изменялась). Полез в исходник, нашел место, где проверялась картинка. Оказывается, туда можно было приложить не только картинку, но и архив и еще несколько видов файлов, потому проверка шла просто по расширению файла (в других местах вызывались функции работы с картинками и проверялось содержимое). Веб-сервер был настроен так, что если даже залить скрипт под расширением jpg, то исполнен он не будет.
Но заметил, что в исходнике использовалась фукнция, которая имела ограничение на длину файла. В итоге создав файлик shell___ (точно не помню сколько подчеркиваний)_.jpg.php, я добился того, что функция увидела все включая .jpg, но не дальше. А веб-сервер видел полный путь, собственно, залив такой файлик я сразу получил шелл.
А сколько бы я долбался с сайтом на шареде, чтобы найти все формы (оставляя следы в логах), потом прикидывая варианты, как туда залить шелл (о том, как именно проверялось имя файла я ж не знал, а стандартная фукнция в актуальной на тот момент версии php работала корректно, отличие от версии из какой-то популярной но сторонней библиотеки (вроде PEAR).
Это не поиск уязвимостей, а обычный скрипт-кидди подход (:
Вам всякой видней=)
Не поделитесь информацией о том, как крутой спец по поиску уязвимостей, находил бы эту или другую дырку?
Гугл вам поможет.
А, ну конечно. Вы просто тролль, который с проверкой на безопасность никогда дела не имел, непонятно зачем решил поумничать. Главное — результат. Если сработает популярный эксплоит — тем проще. Не сработает — идем дальше. В данном случае, никаких эксплоитов вообще не применялось, хотя при профессиональном взломе их используют на ура.
Вот можете почитать, как ломали бигмир: dnevnik.bigmir.net/groups/article/52157/
А вы можете и дальше расставлять пальцы, рассказывая о скрипт-кидди и на конкретные вопросы отвечать посылом в гугл без конкретики.
Вот можете почитать, как ломали бигмир: dnevnik.bigmir.net/groups/article/52157/
А вы можете и дальше расставлять пальцы, рассказывая о скрипт-кидди и на конкретные вопросы отвечать посылом в гугл без конкретики.
Не хватает конкретики. Приведите примеры разработанных сайтов, напишите, сколько времени заняла их разработка.
У меня был заказчик, точнее он есть и сейчас. Просил поставить CMS, в последствии оказалось что ему нужен сайт с кучей логики, а CMS ему нужна была только для того, чтобы забивать контент страниц (т.е. по сути только wysiwyg). Хорошо что я сразу поставил гем
active_admin, но сейчас получается, что даже его не хватает чтобы ввести данные. Так что я полностью согласен с автором статьи. Жаль, что плюсануть не могу…Некоторые CMS позволяют создавать свои типы материалов со сложной логикой. Drupal например.
Я на нем биллинговую систему делал с отправкой уведомлений по SMS.
В каком то смысле drupal — это не CMS, а фреймворк для создания той CMS, которую вы хотите.
В каком то смысле drupal — это не CMS, а фреймворк для создания той CMS, которую вы хотите.
Многие Drupal относят к CMF (Content Management Framework). Хотя я бы подчеркнул его дуалистическую природу — он в зависимости от того как его используешь — может быть или CMS, или CMF.
Его так и позиционируют: CMF(P) (Content Management Framework/Platform) — Вики, Друпал.
Лично я согласен с позицией автора конкретно о веб-приложениях. Друпал силен, и сила его в модулях, почти всегда можно найти модуль, который решает конкретно твою задачу. Но базовый принцип работы Друпала остается прежним, и для внесения изменения в архитектуру надо хакать ядро, а это автоматический отказ от обновлений — привет кракерам.
Вот, к примеру, работа с БД. Долгое время в Друпале поддерживался только MySQL, недавно впилили PostreSQL. А большинство модулей остались совместимы лишь с MySQL. Так и живем…
Короче, не катит Друпал на роль CMF для веб-приложений, имхо.
Лично я согласен с позицией автора конкретно о веб-приложениях. Друпал силен, и сила его в модулях, почти всегда можно найти модуль, который решает конкретно твою задачу. Но базовый принцип работы Друпала остается прежним, и для внесения изменения в архитектуру надо хакать ядро, а это автоматический отказ от обновлений — привет кракерам.
Вот, к примеру, работа с БД. Долгое время в Друпале поддерживался только MySQL, недавно впилили PostreSQL. А большинство модулей остались совместимы лишь с MySQL. Так и живем…
Короче, не катит Друпал на роль CMF для веб-приложений, имхо.
Вот, к примеру, работа с БД. Долгое время в Друпале поддерживался только MySQL, недавно впилили PostreSQL. А большинство модулей остались совместимы лишь с MySQL. Так и живем…
Вы на какой версии работе-то?
Поддержка PostgreSQL появилась еще в версии 4.7.0, а она вышла в 2006 году.
Также ничто не мешает прикрутить поддержку своей БД, не хакая ядро.
Вы на какой версии работе-то?
Поддержка PostgreSQL появилась еще в версии 4.7.0, а она вышла в 2006 году.
Также ничто не мешает прикрутить поддержку своей БД, не хакая ядро.
Поддерживаю, даже драйвер для MSSQL есть (в 7-ой версии). Поначалу косяки с ним были, когда drupal 7 ещё в бете был. Сейчас допилили насколько я знаю.
На шестерке. Да, признаю, с «недавно» я погорячился, разбирался с этим давно, поэтому с временем промазал. Но суть это не меняет — многие модули по-прежнему заточены по мускул. Да, популярные модули вроде сделали СУБД-независимыми (и то вопрос, по-моему в узких местах все-равно стоят dbms-specific хаки), но таких меньшинство.
На семерку переходить не спешу, т.к. плюшки неочевидны, а работы с переносом — воз. Да и та же фигня с модулями — многие не портированы на семерку.
На семерку переходить не спешу, т.к. плюшки неочевидны, а работы с переносом — воз. Да и та же фигня с модулями — многие не портированы на семерку.
Назовите, пожалуйста, жизненно необходимые модули, которые работаю только с MySQL.
Я встречал только один модуль, работающий только с MySQL, название сейчас не скажу, т.к. им не пользовался.
Для семерки уже вышли стабильными многие необходимые модули (Views, Rules и т.д.), так что, я считаю, что сейчас новые проекты стоит делать уже на семерке.
Я встречал только один модуль, работающий только с MySQL, название сейчас не скажу, т.к. им не пользовался.
Для семерки уже вышли стабильными многие необходимые модули (Views, Rules и т.д.), так что, я считаю, что сейчас новые проекты стоит делать уже на семерке.
Похоже, я порю горячку. :)
Лично я ни разу не столкнулся с проблемой адаптации модуля к PostgreSQL, знаю о них лишь понаслышке. Мой опыт сильно устарел: я знакомился с Друпал в 2009-м, а тогда нередко сообщали о багах в работе с PostreSQL. В свое оправдание могу лишь предложить загуглить postgresql drupal 6 site:drupal.org. Сейчас, похоже, всё устаканилось. Посыпаю голову пеплом.
> сейчас новые проекты стоит делать уже на семерке
с этим я не спорю, я имел в виду поддержку старых проектов.
Лично я ни разу не столкнулся с проблемой адаптации модуля к PostgreSQL, знаю о них лишь понаслышке. Мой опыт сильно устарел: я знакомился с Друпал в 2009-м, а тогда нередко сообщали о багах в работе с PostreSQL. В свое оправдание могу лишь предложить загуглить postgresql drupal 6 site:drupal.org. Сейчас, похоже, всё устаканилось. Посыпаю голову пеплом.
> сейчас новые проекты стоит делать уже на семерке
с этим я не спорю, я имел в виду поддержку старых проектов.
А какие в друпале транзакции, ох такая там транзакции… 6-ая версия…
Система безусловно неплохая, но архитектура крайне древняя, систему хуков давно пора уже на помойку. Поэтому современным требованиям она соответствует все меньше и меньше. Хотя справедливости ради замечу, что это касается большей части систем, в том числе и платных. Я о продуктах общего назначения, ибо понятно, что есть достаточно неплохие нишевые решения.
Система безусловно неплохая, но архитектура крайне древняя, систему хуков давно пора уже на помойку. Поэтому современным требованиям она соответствует все меньше и меньше. Хотя справедливости ради замечу, что это касается большей части систем, в том числе и платных. Я о продуктах общего назначения, ибо понятно, что есть достаточно неплохие нишевые решения.
Чем хуки плохи?
А чего они хороши? В глобальной зоне видимости свалили гигантскую кучу… функций, в глобальной же зоне гоняются данные от модуля к модулю в которых они могут быть изменены и фиг ты узнаешь, какая же сволочь выше по коду слила данные. Точнее рано или поздно это выясняется, но это удорожает сапорт такой системы.
Куски html-я генерируемые в самих модулях то еще извращение. Все равно при кастомной разработке понадобится свое, так почему бы не отдать просто данные, и уж сам решу, как их в html-е представить.
В общем понятно, почему так. Когда закладывалась архитектура по другому сделать было нельзя, приходилось делать некую эмуляцию ООП на процедурном по сути языке. Но сейчас инструменты позволяющие решать эти проблемы более удобно, но просто иметь волю взять все и выкинуть написал архитектуру с нуля. Тем пачем друпал между мажорными ветками леганси код не тащил. Но нет…
В общем необходимость в перепроектировании есть, а готового продукта общего назначения уже нет. И вопрос буквально 3-5 лет когда он таки появится. Возможно это даже будет пересмотренный архитектурно друпал, может другая система, это не принципиально, важно, что точно ни одна из текущих в настоящим их виде.
Куски html-я генерируемые в самих модулях то еще извращение. Все равно при кастомной разработке понадобится свое, так почему бы не отдать просто данные, и уж сам решу, как их в html-е представить.
В общем понятно, почему так. Когда закладывалась архитектура по другому сделать было нельзя, приходилось делать некую эмуляцию ООП на процедурном по сути языке. Но сейчас инструменты позволяющие решать эти проблемы более удобно, но просто иметь волю взять все и выкинуть написал архитектуру с нуля. Тем пачем друпал между мажорными ветками леганси код не тащил. Но нет…
В общем необходимость в перепроектировании есть, а готового продукта общего назначения уже нет. И вопрос буквально 3-5 лет когда он таки появится. Возможно это даже будет пересмотренный архитектурно друпал, может другая система, это не принципиально, важно, что точно ни одна из текущих в настоящим их виде.
Хуки позволяют вмешиваться в процесс работы системы, не правя ядро. Причем из одного модуля можно вмешаться в работу другого модуля.
Куски html-я генерируемые в самих модулях то еще извращение. Все равно при кастомной разработке понадобится свое, так почему бы не отдать просто данные, и уж сам решу, как их в html-е представить.
Не всегда нужно кастомное решение, часто хватает стандартного решения. Если же все равно нужно кастомное решение — то ничто не мешает взять за основу стандартное решение и переопределить его в своей теме/модуле.
Насчет ООП сам не могу сказать, но знающие люди говорили, что в Друпале ООП применяется там где это необходимо и не применяется там, где без него можно обойтись.
P.S. Архитектура Друпала очень сильно меняется от версии к версии, посмотрите хотя бы на изменения 7 версии по сравнению с 6-ой.
Куски html-я генерируемые в самих модулях то еще извращение. Все равно при кастомной разработке понадобится свое, так почему бы не отдать просто данные, и уж сам решу, как их в html-е представить.
Не всегда нужно кастомное решение, часто хватает стандартного решения. Если же все равно нужно кастомное решение — то ничто не мешает взять за основу стандартное решение и переопределить его в своей теме/модуле.
Насчет ООП сам не могу сказать, но знающие люди говорили, что в Друпале ООП применяется там где это необходимо и не применяется там, где без него можно обойтись.
P.S. Архитектура Друпала очень сильно меняется от версии к версии, посмотрите хотя бы на изменения 7 версии по сравнению с 6-ой.
И плохо, что из одного модуля можно вмешаться в работу другого. Качество реализации многих модулей оставляет сильно желать лучшего.
Если требуется что-то не сложнее домашней странички, то да, не кастомных решений хватает, но что-то чуть сложнее и начинаются грабли с правкой модулей или приворачивания других костылей. В итоге очень сильно теряем на сапорте кода такой системы.
Знающие люди видимо мало видели хороших систем просто. Друпал 6 огромный кусок атавизма, неплохой уровень ООП есть только в свежих модулях и то, сильно зависит от автора модуля. Само же ядро кусок атавизма. 7-ка чуть лучше, но сырая.
И проблема не в наличие или отсутствии ООП. А в том, что в наше время процедурный подход на такой архитектуре усложняет поддержку кода такой системы. И добавление ООП автоматически не делает более удобной работу, тут еще и архитектурно это правильно сделать нужно. Печальность ситуации в том, что сейчас нет систем общего назначения отвечающим современным требованиям к веб приложениям. Нишевые решения есть, общего назначения нет. И ни друпал 7, ни даже 8 не обещают нам, что такая система появится из друпал проекта.
Если требуется что-то не сложнее домашней странички, то да, не кастомных решений хватает, но что-то чуть сложнее и начинаются грабли с правкой модулей или приворачивания других костылей. В итоге очень сильно теряем на сапорте кода такой системы.
Знающие люди видимо мало видели хороших систем просто. Друпал 6 огромный кусок атавизма, неплохой уровень ООП есть только в свежих модулях и то, сильно зависит от автора модуля. Само же ядро кусок атавизма. 7-ка чуть лучше, но сырая.
И проблема не в наличие или отсутствии ООП. А в том, что в наше время процедурный подход на такой архитектуре усложняет поддержку кода такой системы. И добавление ООП автоматически не делает более удобной работу, тут еще и архитектурно это правильно сделать нужно. Печальность ситуации в том, что сейчас нет систем общего назначения отвечающим современным требованиям к веб приложениям. Нишевые решения есть, общего назначения нет. И ни друпал 7, ни даже 8 не обещают нам, что такая система появится из друпал проекта.
Хуки позволяют вмешиваться в процесс работы системы, не правя ядро. Причем из одного модуля можно вмешаться в работу другого модуля.Есть и другие механизмы, позволяющие делать то же самое, но более гибко.
ООП применяется там где это необходимо и не применяется там, где без него можно обойтись.Что можно обойтись ещё не значит, что нужно обходиться.
ООП не серебряная пуля, как и любой другой подход, и точно также не значит, что там где без него можно обойтись, его надо обязательно прививать.
Архитектура у друпала не идеальная конечно, но достаточно гибкая, и без повсеместного применения ООП. Копий по этому поводу сломано множество, можно почитать на drupal.org
Архитектура у друпала не идеальная конечно, но достаточно гибкая, и без повсеместного применения ООП. Копий по этому поводу сломано множество, можно почитать на drupal.org
Для веб-приложений лучше будет разработать архитектуру, а сайт может обойтись и CMS. А если прекратить писать на php, то вопросы CMS отпадут сами собой
> Плюсы CMS:
> оттестированный проверенный многими разработчиками код
Я испытал смешанные чувства, когда прочел это. С одной стороны мне было очень смешно, с другой стороны я ужаснулся, насколько человек может заблуждаться.
> оттестированный проверенный многими разработчиками код
Я испытал смешанные чувства, когда прочел это. С одной стороны мне было очень смешно, с другой стороны я ужаснулся, насколько человек может заблуждаться.
Не совсем понятно что подразумевается под веб-приложение?
Если речь идет о сложной многопользовательской игре, то вообще о какой CMS можно говорить? Тут как бы свой базу данных не пришлось писать.
Вы различаете CMS и Framework? Написанное относится к обоим, я так понимаю?
(Я не против, эта грань все больше расплывается и это правильно, CMF — вот гибкий инструмент, который позволяет быстро сделать прототип и сколько угодно времени кастомизировать, начиная с приоритетных вещей)
Очень мало задач, где можно упереться в ограничения современной CMS/CMF и тем более Framework.
Схемы вообще не о чем, что вам мешает к CMS дописать fronend и backend на чем угодно? Уже давно в моделях нет echo 'html', а много где можно гибко настроить вывод данных хоть в xml.
По минусам, тоже, ерунда. С чего это внесение изменений в логику проблематично? По мне, написать с нуля намного проблематичней. Убрать лишний функционал/перегруженный интерфейс, тоже, легче. И заметьте, пока вы это делаете, сайт уже работает и выполняет свои функции. Предметная область, единственное с чем можно согласится, но это просто минус, он мало что меняет.
В общем, больше похоже на «мне тяжело разбираться с CMS, потому я хочу написать с нуля, нужно это как-то обосновать».
Если речь идет о сложной многопользовательской игре, то вообще о какой CMS можно говорить? Тут как бы свой базу данных не пришлось писать.
Вы различаете CMS и Framework? Написанное относится к обоим, я так понимаю?
(Я не против, эта грань все больше расплывается и это правильно, CMF — вот гибкий инструмент, который позволяет быстро сделать прототип и сколько угодно времени кастомизировать, начиная с приоритетных вещей)
Очень мало задач, где можно упереться в ограничения современной CMS/CMF и тем более Framework.
Схемы вообще не о чем, что вам мешает к CMS дописать fronend и backend на чем угодно? Уже давно в моделях нет echo 'html', а много где можно гибко настроить вывод данных хоть в xml.
По минусам, тоже, ерунда. С чего это внесение изменений в логику проблематично? По мне, написать с нуля намного проблематичней. Убрать лишний функционал/перегруженный интерфейс, тоже, легче. И заметьте, пока вы это делаете, сайт уже работает и выполняет свои функции. Предметная область, единственное с чем можно согласится, но это просто минус, он мало что меняет.
В общем, больше похоже на «мне тяжело разбираться с CMS, потому я хочу написать с нуля, нужно это как-то обосновать».
>>Вы различаете CMS и Framework? Написанное относится к обоим, я так понимаю?
написанное относится к CMS.
>>упереться в ограничения
вы имеете ввиду когда «это трудно сделать», или «это невозможно сделать»?
>>сайт уже работает и выполняет свои функции
если под функциями понимается просто отображение контента — то это примерно одинаково просто делать и с CMS и без нее. речь идет о том, когда добавляются задачи выходящие за рамки — «эта запись в БД -> эта страничка на сайте». Но когда необходимо добавить свою логику, правила отображения информации, получения информации, определенную валидацию не предусмотренную CMS — тогда надо будет либо править код CMS, либо писать модуль (если задачу можно решить при помощи модулей). Но написание модуля само по себе является добавлением нового звена, и сами правила создания модулей могут накладывать ограничения.
>>По мне, написать с нуля намного проблематичней
В начале возможно объем кода будет больше, при дальнейшем развитии — вносить изменения будет проще и дешевле.
>>что вам мешает к CMS дописать fronend и backend на чем угодно
А зачем простите тогда вообще нужна CMS?
написанное относится к CMS.
>>упереться в ограничения
вы имеете ввиду когда «это трудно сделать», или «это невозможно сделать»?
>>сайт уже работает и выполняет свои функции
если под функциями понимается просто отображение контента — то это примерно одинаково просто делать и с CMS и без нее. речь идет о том, когда добавляются задачи выходящие за рамки — «эта запись в БД -> эта страничка на сайте». Но когда необходимо добавить свою логику, правила отображения информации, получения информации, определенную валидацию не предусмотренную CMS — тогда надо будет либо править код CMS, либо писать модуль (если задачу можно решить при помощи модулей). Но написание модуля само по себе является добавлением нового звена, и сами правила создания модулей могут накладывать ограничения.
>>По мне, написать с нуля намного проблематичней
В начале возможно объем кода будет больше, при дальнейшем развитии — вносить изменения будет проще и дешевле.
>>что вам мешает к CMS дописать fronend и backend на чем угодно
А зачем простите тогда вообще нужна CMS?
> написанное относится к CMS.
CMS CMS-у рознь.
> вы имеете ввиду когда «это трудно сделать», или «это невозможно сделать»?
Я имею в виду, что CMS вряд ли чем-то помешает реализовать что-либо. Если вы выбрали правильную CMS.
> когда добавляются задачи выходящие за рамки
Пример? Второй раз задаю этот вопрос, что подразумевается под вашим веб-приложением? Возможно, я с вами соглашусь. Я не знаю о чем мы говорим, но сфера применения CMS явно не ограничивается сайтами-визитками, даже там, где бюджет не ограничен.
> В начале возможно объем кода будет больше, при дальнейшем
> развитии — вносить изменения будет проще и дешевле.
Какая разница? Бизнес-логика мало касается архитектуры приложения, а основная работа с ней.
> А зачем простите тогда вообще нужна CMS?
Бизнес-логика — основное. Формочки делать легко, быстро и приятно хоть на HTML хоть на Flash, Java, Delphi, ets.
CMS CMS-у рознь.
> вы имеете ввиду когда «это трудно сделать», или «это невозможно сделать»?
Я имею в виду, что CMS вряд ли чем-то помешает реализовать что-либо. Если вы выбрали правильную CMS.
> когда добавляются задачи выходящие за рамки
Пример? Второй раз задаю этот вопрос, что подразумевается под вашим веб-приложением? Возможно, я с вами соглашусь. Я не знаю о чем мы говорим, но сфера применения CMS явно не ограничивается сайтами-визитками, даже там, где бюджет не ограничен.
> В начале возможно объем кода будет больше, при дальнейшем
> развитии — вносить изменения будет проще и дешевле.
Какая разница? Бизнес-логика мало касается архитектуры приложения, а основная работа с ней.
> А зачем простите тогда вообще нужна CMS?
Бизнес-логика — основное. Формочки делать легко, быстро и приятно хоть на HTML хоть на Flash, Java, Delphi, ets.
>Очень мало задач, где можно упереться в ограничения современной CMS
Шутите? Пример задачи, в каменте выше: habrahabr.ru/blogs/refactoring/138435/#comment_4622931
Я работа с Drupal, MODx, Bitrix в том числе и модифицировал ядро. И могу сказать, что без допилки указанная задача не реализуемая ни в одной из них.
Шутите? Пример задачи, в каменте выше: habrahabr.ru/blogs/refactoring/138435/#comment_4622931
Я работа с Drupal, MODx, Bitrix в том числе и модифицировал ядро. И могу сказать, что без допилки указанная задача не реализуемая ни в одной из них.
Ощущение, что вы многие доводы с потолка взяли, либо не понимаете их весомости. К примеру, про предметную область cms. Вы в вордпрессе можете дописать свои необходимые модели уже в рамках устоявшейся архитектуры гораздо быстрее, чем писать с нуля, и cms вам скорее будет содействовать, чем мешать, так как вы не будете над каждой задачей ломать голову, а будете делать по конвенциям архитектуры, что переведет этот пункт в плюсы. Уж не обессудьте, я не буду проводить анализ, но критически можно посмотреть на любое ваше утверждение.
Вы не внесли никаких измеримых/сравнимых параметров, по которым можно было бы сравнить cms/написание своей системы. Хотя бы строчки кода сосчитали. Надо хоть какую-то объективность нести исследованием, а не просто свои ощущения излагать. Внести кейс проекта хотя-бы.
Вы не внесли никаких измеримых/сравнимых параметров, по которым можно было бы сравнить cms/написание своей системы. Хотя бы строчки кода сосчитали. Надо хоть какую-то объективность нести исследованием, а не просто свои ощущения излагать. Внести кейс проекта хотя-бы.
UFO just landed and posted this here
Мне кажется, вопрос с использованием CMS в другом. Много ли людей, которые реально готовы писать много кода под CMS, зная архитектуру в деталях?
Не будет ли так, что со временем большая часть кода будет не от CMS, стоит ли это использования готовых наработок.
Ну и основной вопрос, который у меня возникает, когда я вижу друпал. Где у него контроль целостности на уровне базы данных? Я не могу воспринимать всерьёз заявления что это и не нужно.
Не будет ли так, что со временем большая часть кода будет не от CMS, стоит ли это использования готовых наработок.
Ну и основной вопрос, который у меня возникает, когда я вижу друпал. Где у него контроль целостности на уровне базы данных? Я не могу воспринимать всерьёз заявления что это и не нужно.
UFO just landed and posted this here
> Не будет ли так, что со временем большая часть кода будет не от CMS, стоит ли это использования готовых наработок.
будет.
но пройдет еще год, разработчик будет работать над своим кодом, делать его расширяемым, масштабируемым
и вдруг увидит что в результате переписал тут CMS с которой начал.
наверное, этот путь должен пройти каждый разработчик.
будет.
но пройдет еще год, разработчик будет работать над своим кодом, делать его расширяемым, масштабируемым
и вдруг увидит что в результате переписал тут CMS с которой начал.
наверное, этот путь должен пройти каждый разработчик.
UFO just landed and posted this here
Это вранье!
Возьмите любую популярную CMS — это сборник костылей(говнокода) и велосипедов.
Яркий пример wordpress: процедурное программирование, множественные точки входа, конструктор запросов(велосипед, вместо классического builder), об оптимизации исполнения вообще говорить не приходится: wordpress 3 ест 30 метров оперативки — на shared хостинге у Вас просто на загрузится админка.
А еще я писал модуль для Joomla 1.5 и Drupal 6… Рассказывать не буду, кто знает тот поймет.
Меня очень радует что разработчики drupal 8 будут использовать symfony. Надеюсь что-то изменится и drupal можно будет вычеркнуть из этого списка.
Возьмите любую популярную CMS — это сборник костылей(говнокода) и велосипедов.
Яркий пример wordpress: процедурное программирование, множественные точки входа, конструктор запросов(велосипед, вместо классического builder), об оптимизации исполнения вообще говорить не приходится: wordpress 3 ест 30 метров оперативки — на shared хостинге у Вас просто на загрузится админка.
А еще я писал модуль для Joomla 1.5 и Drupal 6… Рассказывать не буду, кто знает тот поймет.
Меня очень радует что разработчики drupal 8 будут использовать symfony. Надеюсь что-то изменится и drupal можно будет вычеркнуть из этого списка.
То есть вы хотите сказать, что ваша собственная ЦМС лишена всех этих недостатков?
Решитесь показать код?
Решитесь показать код?
Увы, они будут использовать не Symfony, а Symfony Components и то, кажется, только HttpFoundation. То есть архитектура и концепции останутся старыми, только кое-где будут использоваться сторонние разработки вместо своих велосипедов.
А бич многих (большинства? всех?) популярных CMS — необходимость обратной совместимости хотя бы на уровне идеологии и концептов. По сути развитие популярных CMS на PHP повторяет развитие самого PHP — вроде вводятся новые фичи и концепции, но от старых не отказываются, даже если современным требованиями они явно не отвечают. Количество унаследованного кода столь велико, что полный отказ от BC чреват потерей аудитории. Грубо говоря, при качественной потере BC не будет необходимости использовать ноую версию, а можно пойти к конкурентам, которые столь резкие для разработчиков и их клиентов шаги не делают.
А бич многих (большинства? всех?) популярных CMS — необходимость обратной совместимости хотя бы на уровне идеологии и концептов. По сути развитие популярных CMS на PHP повторяет развитие самого PHP — вроде вводятся новые фичи и концепции, но от старых не отказываются, даже если современным требованиями они явно не отвечают. Количество унаследованного кода столь велико, что полный отказ от BC чреват потерей аудитории. Грубо говоря, при качественной потере BC не будет необходимости использовать ноую версию, а можно пойти к конкурентам, которые столь резкие для разработчиков и их клиентов шаги не делают.
Рано или поздно от леганси отказаться придется. Требования к приложениям усложняются и сапортить леганси код который архитектурно заложен по айтишным меркам чуть ли не в другую эпоху становиться накладно.
Система которая сможет соблюсти баланс удобства сапорта, быстро разработки и кастомизации просто вытеснит остальных чисто эволюционно.
Система которая сможет соблюсти баланс удобства сапорта, быстро разработки и кастомизации просто вытеснит остальных чисто эволюционно.
хорошая статья, будет полезна.
сколько раз пытался доказать и натыкался на стену,
сколько раз наступали сами на грабли с использованием готовых решений,
опыт подсказывает, что если нужна функциональность боле чем на 50%, отличная готовых решений, то использование собственных наработок более выгодно.
сколько раз пытался доказать и натыкался на стену,
сколько раз наступали сами на грабли с использованием готовых решений,
опыт подсказывает, что если нужна функциональность боле чем на 50%, отличная готовых решений, то использование собственных наработок более выгодно.
UFO just landed and posted this here
Статье на мой взгляд не хватает примера конкретного сайта и времени разработки.
Как по мне — именно поэтому такую популярность набирают веб-MVC-фреймворки вкупе с офигенными штуками типа Twitter Bootstrap. Когда ничто не ограничивает в описании предметной области, но при этом отдельные инструменты/компоненты/контролы уже есть. Получается и быстро, и гибко.
Сам давно считаю, что «CMS» в привычном понимании нафиг не сдался в большинстве случаев. CMS, по определению, должен управлять контентом/данными конечного проекта. Почему-то исторически сложилось так, что CMS должна уметь создавать/развертывать проект, а заодно делать «без привлечения разработчиков» (но через красивый веб-UI) те вещи, которые по-хорошему доджны быть написаны небольшим количеством простого кода. В итоге получаются монстрообразные штуки, и вакансии типа «нужен высококлассный спец по Битриксу». На кой черт системе, которая «простая, быстрая, и работает без разработчика» нужны высококлассные спецы? То есть… получается что все-таки нужны? Тогда нафига там вся эта хрень, если спец проще сделает это в коде?
Но в конечном итоге для хорошего разработчика — с современным набором из MVC (на нужной платформе)/HTML/JS/jQuery/SASS/LESS/Bootstrap/Backbone.js/etc — получается быстрее, производительнее, гибче и «поддерживаемее» создать кастомное решение. То, что в такой системе можно назвать «CMS» — очень далеко от монструозных конструкторов всего и вся. Ибо если уж работает разработчик — ему куда проще сделать некоторые вещи прямо в коде, нежели разбираться с ворохом тяжеловесных абстракций. А конечному пользователю предоставить специально созданный под задачу простой UI для «управления контентом».
И получаем — либо проект «слишком прост» для «CMS», либо слишком сложен.
Сам давно считаю, что «CMS» в привычном понимании нафиг не сдался в большинстве случаев. CMS, по определению, должен управлять контентом/данными конечного проекта. Почему-то исторически сложилось так, что CMS должна уметь создавать/развертывать проект, а заодно делать «без привлечения разработчиков» (но через красивый веб-UI) те вещи, которые по-хорошему доджны быть написаны небольшим количеством простого кода. В итоге получаются монстрообразные штуки, и вакансии типа «нужен высококлассный спец по Битриксу». На кой черт системе, которая «простая, быстрая, и работает без разработчика» нужны высококлассные спецы? То есть… получается что все-таки нужны? Тогда нафига там вся эта хрень, если спец проще сделает это в коде?
Но в конечном итоге для хорошего разработчика — с современным набором из MVC (на нужной платформе)/HTML/JS/jQuery/SASS/LESS/Bootstrap/Backbone.js/etc — получается быстрее, производительнее, гибче и «поддерживаемее» создать кастомное решение. То, что в такой системе можно назвать «CMS» — очень далеко от монструозных конструкторов всего и вся. Ибо если уж работает разработчик — ему куда проще сделать некоторые вещи прямо в коде, нежели разбираться с ворохом тяжеловесных абстракций. А конечному пользователю предоставить специально созданный под задачу простой UI для «управления контентом».
И получаем — либо проект «слишком прост» для «CMS», либо слишком сложен.
>То есть… получается что все-таки нужны? Тогда нафига там вся эта хрень, если спец проще
> сделает это в коде?
Так все просто. Маркетинг. Чего у них не отнять, так это умение правильно провести компанию что бы втюхать конечному потребителю свой продукт. Я не хочу сказать, что он так уж ужасен, но он ни чего не лучше перед бесплатными аналогами. Но его очень хорошо втюхивают. Конечно, чуть позже начиная работать с системой клиент понимает не такая она быстрая, что разработчик нужен и что ему нужна еще куча фичь которых просто нет. Но денежки ту-ту… И приходит к нему специалист по битриксу и клиент понимает, что приключения только еще начинаются.
> сделает это в коде?
Так все просто. Маркетинг. Чего у них не отнять, так это умение правильно провести компанию что бы втюхать конечному потребителю свой продукт. Я не хочу сказать, что он так уж ужасен, но он ни чего не лучше перед бесплатными аналогами. Но его очень хорошо втюхивают. Конечно, чуть позже начиная работать с системой клиент понимает не такая она быстрая, что разработчик нужен и что ему нужна еще куча фичь которых просто нет. Но денежки ту-ту… И приходит к нему специалист по битриксу и клиент понимает, что приключения только еще начинаются.
Полностью согласен про маркетинг, тут ничего не попишешь. Но в целом, изживают себя такие системы, на мой взгляд.
Это если только о Bitrix говорить. Но в принципе это всё относится к любой популярной CMS. Их плюс в том, что действительно можно развернуть проект с минимальной или даже средней функциональностью без привлечения разработчиков, только силами «веб-мастера». Но шаг в сторону от «мэйнстрима» и разработчиков нужно привлекать.
Я обычно сужу о целесообразности использования CMS примерной оценкой какое количество фич CMS будет использоваться в проекте и какой количество фич проекта может быть реализовано CMS (и её доступными модулями). С учётом перспективы где-то на год. Если первое число мало, а второе велико, то CMS использовать нецелесообразно — большую часть фич придётся всё равно писать самому, а широкие возможности CMS будут только мешать, да ещё будешь загнан в рамки архитектуры, как правило не самой удачной по сравнению с современными лучшими практиками.
Я обычно сужу о целесообразности использования CMS примерной оценкой какое количество фич CMS будет использоваться в проекте и какой количество фич проекта может быть реализовано CMS (и её доступными модулями). С учётом перспективы где-то на год. Если первое число мало, а второе велико, то CMS использовать нецелесообразно — большую часть фич придётся всё равно писать самому, а широкие возможности CMS будут только мешать, да ещё будешь загнан в рамки архитектуры, как правило не самой удачной по сравнению с современными лучшими практиками.
Лично у меня программирование начиналось с хобби, поэтому своя собственная CMS можно сказать спортивный интерес. Я ковырял много движков ради «посмотреть» как у них там что устроено, с целью отметить для себя самые простые способы реализации сложных механизмов. Из открытых CMS мне если честно не понравилась ни одна. И не потому что они плохи, а потому что их код для меня сильно сложен и мне его тяжелей совершенствовать. Но я нашел в них много интересных алгоритмов, которые реализовал по своему и вполне доволен проделанной работой. Моя CMS предельно проста, имеет архитектуру Ядро-Контроллер-Модель-Представление, общий вес файлов менее 200 КБ, очень быстро работает и потребляет очень мало памяти. Наверняка код — говнокод, хотя бы потому что мне самому есть к чему придраться, зато большей гибкости мне не даст ни одна существующая CMS из коробки.
Что касается «показать код», то уже в марте я планирую раздавать свою CMS всем желающим и обязательно сделаю здесь обзор.
Есть также плюсы и минусы, без них никуда.
Основной плюс, ради чего я думаю ей будут пользоваться — это то, что из головной системы управления можно создавать и редактировать сколько угодно сайтов. То есть можно установить на хостинг как всю CMS, так и два дочерних файла (index.php и .htaccess), и посредством SOAP взаимодействовать с головной системой управления, что дает возможность развивать сразу сеть сайтов, допиливая только одно ядро.
Минус — обязательно нужно знать html/css чтобы пользоваться этой системой управления. Управление шаблонами и другими частями дизайна происходит через формы, а системные вызовы менюшек и других данных вызывается в шаблоне посредством специальных bb-кодов. То есть система будет проста только для разработчиков, для остальных конечно проще будет какой-нибудь вордпресс.
Так вот к чему я это все пишу. Дело в том, что недостатки есть везде, и говнокод тоже, но когда заказчик ставит задачу открыть ему от 50 сайтов, и все их развивать и продвигать, чтобы все они были через два три года в топ 100 поисковых систем (потому я эту CMS и писал), то использовать готовые решения во много раз накладней, и более трудоемко. Чуть что на каком сайте подправить — искать пароли доступа, коннектиться, скачивать, вспоминать что к чему, делать, редактировать, заливать обратно. А тут из одной админки можно сделать 50 разных дизайнов, не вмешиваясь в исходный код.
Разные сайты, в зависимости от задач, часто требуют основываться на разных CMS, потому как некоторые лучше подходят под одну, другие под другую. И если посмотреть на общую картину работы веб разработчика, то проще один раз сделать свое и допиливать уже его на все случаи жизни, чем постоянно разбираться в чем-то другом, мучаясь вопросом, может все-таки сделать свое. И чем раньше разработчик сделает свое решение, тем быстрее ему станет проще жить дальше.
Недостатки видят те, требования которых не удовлетворяются. В моем случае и в моей работе, все CMS кроме моей имеют недостатки, причем настолько существенные, что они просто не подходят мне для работы. В чьем-то другом случае, моя CMS будет иметь кучу недостатков, которые не дадут ему нормально работать и возьмет какое-то другое решение.
Так и в создании сайтов. Кому что удобнее, тот тем и пользуется. Нет подходящего инструмента — сделай его сам.
Что касается «показать код», то уже в марте я планирую раздавать свою CMS всем желающим и обязательно сделаю здесь обзор.
Есть также плюсы и минусы, без них никуда.
Основной плюс, ради чего я думаю ей будут пользоваться — это то, что из головной системы управления можно создавать и редактировать сколько угодно сайтов. То есть можно установить на хостинг как всю CMS, так и два дочерних файла (index.php и .htaccess), и посредством SOAP взаимодействовать с головной системой управления, что дает возможность развивать сразу сеть сайтов, допиливая только одно ядро.
Минус — обязательно нужно знать html/css чтобы пользоваться этой системой управления. Управление шаблонами и другими частями дизайна происходит через формы, а системные вызовы менюшек и других данных вызывается в шаблоне посредством специальных bb-кодов. То есть система будет проста только для разработчиков, для остальных конечно проще будет какой-нибудь вордпресс.
Так вот к чему я это все пишу. Дело в том, что недостатки есть везде, и говнокод тоже, но когда заказчик ставит задачу открыть ему от 50 сайтов, и все их развивать и продвигать, чтобы все они были через два три года в топ 100 поисковых систем (потому я эту CMS и писал), то использовать готовые решения во много раз накладней, и более трудоемко. Чуть что на каком сайте подправить — искать пароли доступа, коннектиться, скачивать, вспоминать что к чему, делать, редактировать, заливать обратно. А тут из одной админки можно сделать 50 разных дизайнов, не вмешиваясь в исходный код.
Разные сайты, в зависимости от задач, часто требуют основываться на разных CMS, потому как некоторые лучше подходят под одну, другие под другую. И если посмотреть на общую картину работы веб разработчика, то проще один раз сделать свое и допиливать уже его на все случаи жизни, чем постоянно разбираться в чем-то другом, мучаясь вопросом, может все-таки сделать свое. И чем раньше разработчик сделает свое решение, тем быстрее ему станет проще жить дальше.
То есть вы хотите сказать, что ваша собственная ЦМС лишена всех этих недостатков?
Недостатки видят те, требования которых не удовлетворяются. В моем случае и в моей работе, все CMS кроме моей имеют недостатки, причем настолько существенные, что они просто не подходят мне для работы. В чьем-то другом случае, моя CMS будет иметь кучу недостатков, которые не дадут ему нормально работать и возьмет какое-то другое решение.
Когда то давно я работал отделочником, наносил венецианские штукатурки. Работал вместе с напарником, это он меня научил всему. Так вот у нас было два одинаковых шпателя, только у меня была ручка обрезана почти до половины, а у него она была целой. У меня рука маленькая, и ручка шпателя упиралась в предплечье, что сильно раздражало и мешало работе, поэтому я ее аккуратно подрезал болгаркой. Напарник считал мой шпатель дефектным, и удивлялся как я вообще могу им работать. Удобство пользования играет немаловажную роль, особенно когда работать этим шпателем приходилось целый день, и изо дня в день.
Так и в создании сайтов. Кому что удобнее, тот тем и пользуется. Нет подходящего инструмента — сделай его сам.
Вообще-то я хотел ответить на этот комментарий, как так получилось?
Рекомендации: посмотреть в сторону RESTfull, освоить nginx. «Головной» сайт обычно не нужен, это кластер тогда получается. Более рационально использовать в движке мульти сайтовость с возможностью полной кастомизации сайтов.
Необходимость знания html/css для создания скинов это как раз плюс. Просто пока еще этот факт очень сильно недооценен.
Необходимость знания html/css для создания скинов это как раз плюс. Просто пока еще этот факт очень сильно недооценен.
Тут еще есть проблема закрытости коммерческих CMS. Bitrix, который тут обсуждается в комментариях, можно упрощенно сравнивать с продуктом той же компании 1C-предприятие — это как CMS для бухгалтерии.
И по факту, это является технологическим инструментом и коммерческой технологией.
Лично мне, не очень нравиться быть винтиком в чужой технологии и быть привязанным к ней, и наверно поэтому я отказался разрабатывать в 1с, хотя мой знакомый, который вербовал в 1С программисты и сулил блестящие перспективы. Как и многие другие разработчики, я испытываю от коммерческих технологий дурной запах зависимости и несвободы.
Конечно, абсолютной свободы не существует, и ты вынужден использовать открытые CMS или быть связанным с другими технологиями. Но тут вопрос — сколько степеней свободы ты при этом испытываешь? И, если ты на столько крут, то в принципе ты можешь форкнуть любые открытые технологии. И в этом есть очень приятный вкус свободы.
И если возвратиться к моему знакомому и 1с-предприятию, то проблема, почему ему необходим 1с разработчик в том, что нужно переписывать всю «конфигурацию» с 7 на 8-ку, из за того, что поддержка 7 закончилась и баги ядра никто фиксить не будет а даже наоборот.
Сравним этот случай например с переходом версий в Joomle. Нет никаких проблем в критической ситуации взять ядро и пофиксить проблему самостоятельно.
Лично как по мне — любые фундаментальные технологии должны быть по возможности свободные и гибкие. Это как фундаментальная наука и исследования.
И по факту, это является технологическим инструментом и коммерческой технологией.
Лично мне, не очень нравиться быть винтиком в чужой технологии и быть привязанным к ней, и наверно поэтому я отказался разрабатывать в 1с, хотя мой знакомый, который вербовал в 1С программисты и сулил блестящие перспективы. Как и многие другие разработчики, я испытываю от коммерческих технологий дурной запах зависимости и несвободы.
Конечно, абсолютной свободы не существует, и ты вынужден использовать открытые CMS или быть связанным с другими технологиями. Но тут вопрос — сколько степеней свободы ты при этом испытываешь? И, если ты на столько крут, то в принципе ты можешь форкнуть любые открытые технологии. И в этом есть очень приятный вкус свободы.
И если возвратиться к моему знакомому и 1с-предприятию, то проблема, почему ему необходим 1с разработчик в том, что нужно переписывать всю «конфигурацию» с 7 на 8-ку, из за того, что поддержка 7 закончилась и баги ядра никто фиксить не будет а даже наоборот.
Сравним этот случай например с переходом версий в Joomle. Нет никаких проблем в критической ситуации взять ядро и пофиксить проблему самостоятельно.
Лично как по мне — любые фундаментальные технологии должны быть по возможности свободные и гибкие. Это как фундаментальная наука и исследования.
Не дадите ссылку на Dynamic Data? Я так понимаю, что это что-то вроде Xataface?
ASP.NET Dynamic Data — это реализация системы скаффолдинга под ASP.NET.
Есть предположения, что при создании системы за образец брались принципы использованные в Rubby on Rails.
Есть предположения, что при создании системы за образец брались принципы использованные в Rubby on Rails.
Автор, как и большинство комментаторов, путает CMS и конструкторы сайтов. CMS в вашем подходе — то, что нагенерил скаффолд.
Почему вы решили, что я их путаю?
Системы работающие по принципу скаффолдинга как раз вполне вписываются предлагаемый подход. Так как они являются одним из составляющих блоков(возможно даже и не обязательных), но не навязывают свою архитектуру.
Если же брать CMS — то разработчику необходимо работать с уже заранее определенной архитектурой, и в большинстве случаев реализовывать логику на уровне модулей CMS, а не на уровне всей системы.
Системы работающие по принципу скаффолдинга как раз вполне вписываются предлагаемый подход. Так как они являются одним из составляющих блоков(возможно даже и не обязательных), но не навязывают свою архитектуру.
Если же брать CMS — то разработчику необходимо работать с уже заранее определенной архитектурой, и в большинстве случаев реализовывать логику на уровне модулей CMS, а не на уровне всей системы.
CMS — это система управления контентом, то есть содержимым. Битрикс — это конструктор, а не CMS, например.
Фреймворки со скаффолдингом тоже навязывают свою архитектуру. Например, подразумевают, что классы моделей наследуются от какого-то абстрактного класса или реализуют какой-то интерфейс.
Если рассматривать вариант где скаффолдинг используется только для генерации форм управления данными(backend), а frontend — отдельная система. И взаимодействуют они только через базу данных — тогда ограничений нет.
Если же это единая система — то необходимость наследования все таки не так жестко ограничивает в реализации архитектуры, как необходимость работать на уровне модулей.
Если же это единая система — то необходимость наследования все таки не так жестко ограничивает в реализации архитектуры, как необходимость работать на уровне модулей.
Много знаете бэкендов, которые не накладывают ограничений на источник данных? Которые одинаково хорошо работают и с SQL базами (допустим, что разницы между отдельными SQL СУБД нет), и с NoSQL, и с, например, «плоскими» файлами?
Не совсем понимаю к чему ваш вопрос.
При разработке проекта мне не нужна система которая «одинаково хорошо работают» с большим количеством баз данных. Мне нужна система которая будет работать с той конкретной базой данных которая будет использоваться в проекте.
При разработке проекта мне не нужна система которая «одинаково хорошо работают» с большим количеством баз данных. Мне нужна система которая будет работать с той конкретной базой данных которая будет использоваться в проекте.
К тому, что такой инструмент тоже навязывает ограничения. Если в ТЗ написано, что для генерации форм управления данными нужно использовать условный MySQLFormGenerator, то выбрать в качестве хранилища для проекта MS SQL или MongoDB вы без дополнительных затрат не сможете, даже если по остальным требованиям они будут подходить лучше.
Мы видимо исходим из разных начальных предположений.
Я предполагаю что при разработке проекта нету изначальных требований по конкретному инструментарию и ПО. То есть SQL, NoSQL или другое хранилище будет использоваться в том случае если его использование наиболее оптимально.
Конечно, если есть некая инфраструктура куда нужно вписаться — тогда надо действовать в рамках этих ограничений. Но этому уже частные случаи которые могут состоять из тысяч разных вариантов.
Но даже в этом случае — разделив задачи отображения информации, управления информацией и логики обработки информации, мы получаем больше свободы, чем когда это все необходимо делать в рамках одной системы.
Я предполагаю что при разработке проекта нету изначальных требований по конкретному инструментарию и ПО. То есть SQL, NoSQL или другое хранилище будет использоваться в том случае если его использование наиболее оптимально.
Конечно, если есть некая инфраструктура куда нужно вписаться — тогда надо действовать в рамках этих ограничений. Но этому уже частные случаи которые могут состоять из тысяч разных вариантов.
Но даже в этом случае — разделив задачи отображения информации, управления информацией и логики обработки информации, мы получаем больше свободы, чем когда это все необходимо делать в рамках одной системы.
Если это сайт-визитка, это одно, а если это информационный портал, то не будете же сами наполнять сайт контентом в процессе его развития. Если же сделать интерфейс для редакторов, то получаем уже CMS.
Делаю для себя — пишу на фреймворке, делаю заказчику — использую cms.
Интересно, мне одному кажется, что «веб-приложение» и CMS — просто из разных сказок? CMS нужна для «управления содержимым», а веб-приложение — для реализации конкретной бизнес-задачи.
Понятно, в принципе, что CMS — частный случай веб-приложения, но не наоборот же; как следствие, CMS заведомо не может рассматриваться как основа для веб-приложения.
Понятно, в принципе, что CMS — частный случай веб-приложения, но не наоборот же; как следствие, CMS заведомо не может рассматриваться как основа для веб-приложения.
Те кто использует фреймворки как основной инструмент — давно уже в курсе идей какие автор написал.
И для них это само собой разумеющееся.
И для них это само собой разумеющееся.
Sign up to leave a comment.
Отказ от использования CMS при проектировании веб-приложений