Comments 31
Определите аргументы, почему нужно это делать, почему готовые решения не подходят. Если аргументы будут весомыми, это придаст вам уверенности. Если слабыми, это поможет избежать лишней траты времени.
Почему не подходят готовые решения (популярные CMS). Они тяжеловесные, одновременно избыточные и недостаточные для наших задач.Это даже не слабый ответ, это вообще не ответ на самый основной вопрос. Есть конкретнее?
Обычный ответ: кастомизация под конкретные требования сравнима с написанием с нуля.
Да. Коротко не получится, но постараюсь).
Контекст моего примера — разработка сайтов для автодилеров. Как правило, они небольшой или средней сложности. Но у этого направления есть свои особенности — набор разделов, модулей (у всех есть модельный ряд, у части есть авто с пробегом), требований дистрибьютора к сайту автодилера. И при этом требования могут сильно отличаться, они просто разные у каждого бренда, модельный ряд по структуре контента тоже сильно разнится.
Чтобы сделать на поп.движках решение, удобное для клиента и удовлетворяющее требованиям бренда, нужно приложить сильно больше усилий. Мне довелось посмотреть, как мучается клиент с сайтами, например, на вордпресе, друпале и самописках, когда им сверху спускают требования, а их или не могут выполнить, либо это стоит клиенту дороже.
Или есть бренды, для которых дистрибьютор предлагает дилерскую платформу, в которой кроме пары страниц и своих контактов дилер поменять ничего не сможет, а ему нужно делать seo и продвигаться, т.к. он в Москве, и там конкуренция.
Таким образом, нужно что-то своё, быстрое, легковесное изначально, легко модифицируемое под бренд путём изменения функционала модулей, на базе чего разработчик может быстро развернуть, натянуть верстку, допрограммировать нужный функционал (он бывает очень непростым, конфигураторы, например).
Это если про контекст примера, с которого всё началось. Сейчас наша CMF подходит под множество отраслей.
Контекст моего примера — разработка сайтов для автодилеров. Как правило, они небольшой или средней сложности. Но у этого направления есть свои особенности — набор разделов, модулей (у всех есть модельный ряд, у части есть авто с пробегом), требований дистрибьютора к сайту автодилера. И при этом требования могут сильно отличаться, они просто разные у каждого бренда, модельный ряд по структуре контента тоже сильно разнится.
Чтобы сделать на поп.движках решение, удобное для клиента и удовлетворяющее требованиям бренда, нужно приложить сильно больше усилий. Мне довелось посмотреть, как мучается клиент с сайтами, например, на вордпресе, друпале и самописках, когда им сверху спускают требования, а их или не могут выполнить, либо это стоит клиенту дороже.
Или есть бренды, для которых дистрибьютор предлагает дилерскую платформу, в которой кроме пары страниц и своих контактов дилер поменять ничего не сможет, а ему нужно делать seo и продвигаться, т.к. он в Москве, и там конкуренция.
Таким образом, нужно что-то своё, быстрое, легковесное изначально, легко модифицируемое под бренд путём изменения функционала модулей, на базе чего разработчик может быстро развернуть, натянуть верстку, допрограммировать нужный функционал (он бывает очень непростым, конфигураторы, например).
Это если про контекст примера, с которого всё началось. Сейчас наша CMF подходит под множество отраслей.
UFO just landed and posted this here
Спасибо за подробный ответ, но скорее всего вы просто не знаете существующие инструменты.
В плане автодилеров хорошо знаю кейс, буквально недавно приводили успешно работающий сайт клиента под дизайн и верстку дистрибьютера. Абсолютно никаких проблем, CMS Modx. Вышло тоже быстро и легковесно. Конфигураторы любой сложности делаются легко на основе Vue.js.
Почему вам не подошел MODx и Vue? Вордпресс и друпал действительно была бы боль…
В плане автодилеров хорошо знаю кейс, буквально недавно приводили успешно работающий сайт клиента под дизайн и верстку дистрибьютера. Абсолютно никаких проблем, CMS Modx. Вышло тоже быстро и легковесно. Конфигураторы любой сложности делаются легко на основе Vue.js.
Почему вам не подошел MODx и Vue? Вордпресс и друпал действительно была бы боль…
На тот момент на Modx довелось поработать, Vue ещё не был в поле моего зрения. Но суть не в этом. После рассмотрения нескольких фреймворков и CMS я остановилась на том, что для меня быстрее и лучше всего решит мою задачу. У меня были проекты на фреймворке, 3 года опыта работы на нём на тот момент, сформировалась большая база кода.
Наверняка, на большинстве инструментов можно сделать хороший кейс, если компания на этих инструментах специализируется. В мой пример вы можете подставить любые технологии, если для вас они подходят лучше всего.
Наверняка, на большинстве инструментов можно сделать хороший кейс, если компания на этих инструментах специализируется. В мой пример вы можете подставить любые технологии, если для вас они подходят лучше всего.
Дык любой велосипед по сути и рождается от незнания разработчиком аналогичных готовых решений. Во первых все знать невозможно, а во вторых скорость разработки велосипеда зачастую намного выше, чем поиск и освоение чужих наработок.
При работе с MODx часть разработчиков запихивает товары в текстовые страницы с кучей разных чанков под нужные шаблоны (вместо того чтобы запилить отдельный модуль), отчего большие магазины просто падают, к тому же если не чистить кэш хотя бы раз в месяц, то сайт тоже упадет без видимой на то причины. Это я правда про EVO, с REVO не работал)
Но, в целом, CMF MODx очень даже понравился. Сейчас работаю на студийной CMS самописной и тоже встал вопрос о том, куда и как расти.
Но, в целом, CMF MODx очень даже понравился. Сейчас работаю на студийной CMS самописной и тоже встал вопрос о том, куда и как расти.
Вопрос: существуют CMS не на ПХП? :)
Да, существуют)) Часть написаны/пишутся на C# (asp.net), под IIS сервер. Есть системы на JAVA, там тоже есть ряд апп/веб серверов/фремворков, типа Tomcat, Jetty, Grizzly,Netty, GlassFish, JBoss. А так же варианты и по экзотичней: Ruby, python, perl и т.п.))
Каждый выбирает то, что лучше всего знает. Вот например, я как джавист, цмс творю на Java + Jetty + Postgresql.
В мире шарпа связка обычно Asp.net + IIS + MSSql. Ну, конечно больше всего классического PHP + apache (nginx-fpm) + Mysql.
Если интересны конкретные варианты, то можно поискать на cmsmagazine.ru, там хороший каталог цмс. Например через гугл каким нибудь запросом, типа: <a href=«https://www.google.com.ua/search?q=site%3Awww.cmsmagazine.ru%2Fcatalogue%2F+»asp.net"">site:www.cmsmagazine.ru/catalogue/ «asp.net» вписав соответствующую технологию))
Каждый выбирает то, что лучше всего знает. Вот например, я как джавист, цмс творю на Java + Jetty + Postgresql.
В мире шарпа связка обычно Asp.net + IIS + MSSql. Ну, конечно больше всего классического PHP + apache (nginx-fpm) + Mysql.
Если интересны конкретные варианты, то можно поискать на cmsmagazine.ru, там хороший каталог цмс. Например через гугл каким нибудь запросом, типа: <a href=«https://www.google.com.ua/search?q=site%3Awww.cmsmagazine.ru%2Fcatalogue%2F+»asp.net"">site:www.cmsmagazine.ru/catalogue/ «asp.net» вписав соответствующую технологию))
>> цмс творю на Java + Jetty + Postgresql
jetty — контейнер сервлетов + веб-сервер… неужели код вашей цмс завязан на реализацию jetty и не переносим в другие контейнеры?
jetty — контейнер сервлетов + веб-сервер… неужели код вашей цмс завязан на реализацию jetty и не переносим в другие контейнеры?
Действительно. Может ещё код вашей цмс и на postgresql завязан и не переносим на другие субд?
Не кидайте сильно помидорами, но да)) Код нашего сервиса на текущий момент завязан на embedded Jetty, который стартует наш лаунчер. В дальнейшем рассматривается вариант переписать имплемента́цию веб сервера на Netty, но пока это преждевременная оптимизация.
И для DAO мы используем MyBatis, поэтому переносимости на другие базы нет)) Запросы пишутся с использованием конкретных вкусняшек Postgresql (рекурсивные запросы, возврат Id, явные вызовы сиквенсов, процедуры, планируем постепенно переписать код на использование upsert и т.п)
Так как наша система позиционируется как PaaS, и как коробочная версия не планируется распространятся, система точилась под конкретные решения, в виде java приложения запускаемого на отдельных серверах с возможность горизонтального маштабирования
И для DAO мы используем MyBatis, поэтому переносимости на другие базы нет)) Запросы пишутся с использованием конкретных вкусняшек Postgresql (рекурсивные запросы, возврат Id, явные вызовы сиквенсов, процедуры, планируем постепенно переписать код на использование upsert и т.п)
Так как наша система позиционируется как PaaS, и как коробочная версия не планируется распространятся, система точилась под конкретные решения, в виде java приложения запускаемого на отдельных серверах с возможность горизонтального маштабирования
Но только с вертикально масштабируемой СУБД? Или шардинг тоже предусмотрен?
На текущий момент под сайт идет собственная база (схема). Т.е. можно горизонтально масштабироваться как по воркерам, так и по инстансам субд. Если нагрузка на конкретный сайт уже будет требовать шардинг, то ничего не помешает поставить пару реплик Postgresql в режиме чтения и через pgbouncer раскидать запросы. Исходя из профиля нагрузки (много чтения, мало записи) тут есть хороший простор для вариантов работы со слейвами.
Если уже был взят Codeigniter, то создание CMF свелось к выбору подходящих готовых решений? Или была непосредственно разработка CMF?
Киллер-решение за 100 часов? Я бы глянул, что получилось на выходе. Если в помощь брать джуна, на обучение которого надо тратить время, то посмотреть стало бы еще интереснее. Не примите за наезд, просто пытаюсь понять, может я такой слоупок. На такую фундаментальную штуку, да чтобы еще и с тестами, и все везде хорошо и продуманно, и все фичи желаемые были, я бы часов 800-1000 закинул.
В статье указано, что 100 часов — это «Ресурсы для первого релиза» в условиях совета «Не ставьте слишком больших целей для первого релиза.». В первом релизе было только необходимое на тот момент — абзац «Первый релиз». Я прорабатывала ядро, джун подключился на модулях. Джун работал уже с нами какое-то время, умел пользоваться инструментами, знал фреймворк, поэтому учить уже не пришлось. Плюс, у нас к тому моменту была достаточная база своего кода, поэтому частично использовали наработки.
По самому первому релизу уже нет скрина, но одна из первых версий админки выглядела примерно так: скрин. Там было далеко не всё хорошо и правильно.
С тех пор прошло года 2, за всё время развития CMF было потрачено гораздо больше, чем 100 часов. Это процесс непрерывной разработки, который будет продолжаться. Всегда есть, что исправлять и улучшать.
По самому первому релизу уже нет скрина, но одна из первых версий админки выглядела примерно так: скрин. Там было далеко не всё хорошо и правильно.
С тех пор прошло года 2, за всё время развития CMF было потрачено гораздо больше, чем 100 часов. Это процесс непрерывной разработки, который будет продолжаться. Всегда есть, что исправлять и улучшать.
Есть ли демо-версия или github?
У проекта закрытый код, в общий доступ не выкладываем, сам по себе инструмент не планируем распространять. Демо версии отдельно нет, потому что для клиентов в продажах работает лучше всего — это показать уже готовый сайт реального клиента, который максимально близок — им важен не инструмент, а конечный результат, который решает задачу бизнеса.
Думала в будущей статье рассказать про то, как мы сделали модуль SEO, благодаря которому наши сайты проходят аудит у конкурентов. Там без демо не обойтись и техническое решение частично нужно показать. Тема интересна?
Думала в будущей статье рассказать про то, как мы сделали модуль SEO, благодаря которому наши сайты проходят аудит у конкурентов. Там без демо не обойтись и техническое решение частично нужно показать. Тема интересна?
Как основу выбирайте простой инструмент — язык, базовый фреймворк. С низкой точкой входа, чтобы проще было развивать сам инструмент и проще поддерживать конечные продукты. При этом ему необязательно быть очень популярным, достаточно быть простым. Ещё он должен развиваться
Вас не смущает тот факт что Codeigniter не особо развивается в последнее время, а его архитектура не использует принципы SOLID что способствует проблемам тестирования, масштабируемости, автодополнения в IDE?
Да, он развивается не так интерсивно, как Yii или Laravel. Но развивается. Вот репо 4 версии: https://github.com/bcit-ci/CodeIgniter4. Новость о выходе релиза Pre-Alpha 1 http://blog.newmythmedia.com/blog/show/2016-06-25_Getting_Started_With_CodeIgniter_4_Pre-Alpha_1, вторая фаза почти завершена. С архитектурой у меня и коллег проблем не было. Тестами пользовалась ещё когда была вторая версия. Масштабируем его активно, пример — модульность, HMVC, можно брать и прикручивать либы из других фреймворков, если нужно. С автокомплитом решили тоже ещё со второй версии, работали в нетбинсе, сейчас в phpstorm.
Готов первичный функционал — задокументируйте, что получилось.
Вопрос автору, есть ли какие-то инструменты или чеклист, или может быть онлайн сервис, чтобы задокументировать готовый функционал так, чтобы его мог прочитать другой человек (или я в будущем). Может какие-то графические инструменты…
Из онлайн сервисов могу порекомендовать Read the Docs, и как средство документирования — Генератор документации Sphinx. Если нравится формат wiki, то посмотрите DokuWiki. Может кто-то в комментариях что-то ещё добавит.
Мы у себя используем Sphinx, но не на Read the Docs, а отдельно на нашем сервере. Ещё сделали к нему веб-морду, чтобы с редактором могли работать не только разработчики, но и все сотрудники.
Мы у себя используем Sphinx, но не на Read the Docs, а отдельно на нашем сервере. Ещё сделали к нему веб-морду, чтобы с редактором могли работать не только разработчики, но и все сотрудники.
Отличные советы, испытали все на шкуре https://yupe.ru
Если продукт планируется делать Open Source и для использования другими — можно еще столько же пунктов написать -)
Если продукт планируется делать Open Source и для использования другими — можно еще столько же пунктов написать -)
Имхо, работая в веб-студии пиля однотипные "сайтики" для заказчиков, вполне себе можно запилить свою CMF и продолжить на этой CMF "клепать сайты". Сам работал в веб-студии, сам принял участие в разработке CMF которая является по сей день основной в компании.
Из плюсов такого подхода можно отметить следующее:
1) падаванов научить одной штуке проще, чем 100500 штукам которые представлены на рынке
2) лично я не встречал хороших CMF (ну, мб они есть, но я не видел)
3) потенциально безопаснее (security through obscurity), но это очень спорный вопрос
4) полная свобода действий, ты можешь запилить что угодно, и маловероятно что это сломается с очередным апдейтом "движка", как это бывает в случае использования стороннего ПО.
Минусы конечно тоже есть у этого… Очень часто "свои поделки" не следуют новомодным стандартам и тенденциям (то, о чем я выше написал, к примеру, врядли заработает на PHP7). Нет большого комьюнити которое может указать на недостатки, отправить ПР с фиксом, или что-то подобное. Ну и имеет место быть проблема связанная тем, что мол приходит в компанию человек новый, говорит мол "я знаю симфони, ларавель, юи, там все классно, няшно, бла-бла-бла", а у вас какая-то поделка, и разработчику приходится тратить энное колво времени на изучение этой системы.
Итого, в каких-то случаях плюсы перевешивают, в каких-то — минусы.
Sign up to leave a comment.
Что нужно знать при разработке своих CMF и CMS. Опыт длиною в 2 года