Comments 46
Очень хотелось бы посмотреть, как выглядят CMS Ленты или Ведомостей, чтобы сравнить с тем, что я делаю для своей маленькой редакции :)
Познавательно, спасибо.
сколько разработчиков и за какой срок создали всю эту систему? то есть, с момента написания первых строк кода и конфигов до первого импорта старой базы
Заложили первый кирпич в мае, но продумывать начали раньше.
Количество разработчиков росло с двух, до пяти в момент перезапуска. Это именно ruby разработчики и веб технологи. Импорт готовился примерно месяц. За это время мы полным составом отвлекались на спецпроекты, в частности «Олимпиада-2012», которая была как тест-драйв. После чего много пришлось переделать. В сентябре начали заниматься и фронтендом.
Жарко было последние полтора месяца до перезапуска. Переделка макетов, структуры. Снова переделывать админку, корректировать импорт, перевёрстывать сайт.
Непросто было в следующий месяц – очень много битых ссылок. Даже после перезапуска мы узнавали новое о старом движке.
commit 0ab5de6d50afd9f112d6339f823c2c9f64206f44
Author: Zaur Abasmirzoev <zaur.kavkaz@gmail.com>
Date: Tue May 22 12:14:59 2012 +0400
init
Количество разработчиков росло с двух, до пяти в момент перезапуска. Это именно ruby разработчики и веб технологи. Импорт готовился примерно месяц. За это время мы полным составом отвлекались на спецпроекты, в частности «Олимпиада-2012», которая была как тест-драйв. После чего много пришлось переделать. В сентябре начали заниматься и фронтендом.
Жарко было последние полтора месяца до перезапуска. Переделка макетов, структуры. Снова переделывать админку, корректировать импорт, перевёрстывать сайт.
Непросто было в следующий месяц – очень много битых ссылок. Даже после перезапуска мы узнавали новое о старом движке.
Спасибо!
А как решили вопрос хранилища данных? Скажем, какой-то архив фотографий и материалов, которыми оперируют редакторы и журналисты до того, как выгружать это во фронтенд. Используется свой велосипед для планирования выпусков или готовые решения?
А как решили вопрос хранилища данных? Скажем, какой-то архив фотографий и материалов, которыми оперируют редакторы и журналисты до того, как выгружать это во фронтенд. Используется свой велосипед для планирования выпусков или готовые решения?
Эти задачи решает CMS. Некоторые инструменты для планирования редакционного процесса как раз позволяют заниматься организацией материалов. Медиа-банк как таковой не прижился. Если в журналах такой банк изображений актуален, то в интернет изданиях нет. Не так категорично конечно. Но как есть. Используются подписки на платные фото агенства. По запросу нужная заметка «окартинивается».
Очень интересная статья, и очень информативные комментарии. Помнится, был опыт переноса сайта, пусть и небольшого, с одной CMS на другую. Это был тот еще кошмар, и битые ссылки оказались одним из ужасов, ибо их было много, а сайт без перелинковки не представлял интереса. Пришлось руками править. А еще — картинки… Которые тоже почему-то конфликтовали местами с новой админкой… Поэтому такие статьи, как ваша, помогают понять, к чему готовиться, на чем акцентировать внимание.
UFO just landed and posted this here
Спасибо, очень информативно написано.
Вопрос: какие гемы использовались в Ленте и используются сейчас в Ведомостях? Были гемы, которые не оправдывали себя в процессе разработки и заменялись самописным велосипедом?
Вопрос: какие гемы использовались в Ленте и используются сейчас в Ведомостях? Были гемы, которые не оправдывали себя в процессе разработки и заменялись самописным велосипедом?
Чтобы не получилось простого перечисления слов, мы попробуем ответ на Ваш вопрос оформить отдельной заметкой.
Были разные ситуации. Какие-то библиотеки отпали после выхода rails 4, какие-то доставляли сюрпризов. У нас изменилась архитектура, скажем так существенно. Оттого состав гемов претерпел изменения.
Были разные ситуации. Какие-то библиотеки отпали после выхода rails 4, какие-то доставляли сюрпризов. У нас изменилась архитектура, скажем так существенно. Оттого состав гемов претерпел изменения.
А вот и ответ вам поспел: Набор ruby библиотек для CMS и сайта медиа издания
сдулась лента.ру
*сдублировал коммент случайно*
К моему сожалению ;) нет. Я кстати вообще против паролей!
В совсем старой CMS Ленты был следующий принцип: заходим по общему (auth_basic) логин-паролю, выбираем редактора, с которым будет ассоциирован сеанс, и работаем! Доверие, господа.
Без некоторого соглашения с редакцией об уровне доверия и возможностях трудно будет обеим сторонам. Например если вы редактору не позволяете использовать html теги, embed код, вставки js, которые легким движением могут превратиться в «трояна», то это ограничит его в форматах представления материала. А вас, как разработчика, на каждый такой сценарий заставит реализовать соответсвующий функционал.
В совсем старой CMS Ленты был следующий принцип: заходим по общему (auth_basic) логин-паролю, выбираем редактора, с которым будет ассоциирован сеанс, и работаем! Доверие, господа.
Без некоторого соглашения с редакцией об уровне доверия и возможностях трудно будет обеим сторонам. Например если вы редактору не позволяете использовать html теги, embed код, вставки js, которые легким движением могут превратиться в «трояна», то это ограничит его в форматах представления материала. А вас, как разработчика, на каждый такой сценарий заставит реализовать соответсвующий функционал.
А в этот раз вы не в плейн-тексте храните пароли для новой CMS? :D
Очень структурно и в целом познавательно, спасибо!
Как и почти всегда при взгляде со стороны создается впечатление того, что под капотом проекта всё должно быть глянцево и вылизано при таком подходе (если опираться на то, что видно снаружи сайта, а также на тон и содержание повествования технического специалиста, написанного в стиле «я собой доволен»).
Но положа руку на сердце, если смотреть изнутри, как там на самом деле? Есть говнокод? :) (Который вопреки общей продуманности все-таки возник из-за того что «ну вот так вот здесь получилось» и «сроки-форс-мажоры», и который в итоге так и остался на проекте потому что «итак вобщем-то работает, а исправить и сделать красиво — дорого, когда-нибудь потом может быть...»).
Как и почти всегда при взгляде со стороны создается впечатление того, что под капотом проекта всё должно быть глянцево и вылизано при таком подходе (если опираться на то, что видно снаружи сайта, а также на тон и содержание повествования технического специалиста, написанного в стиле «я собой доволен»).
Но положа руку на сердце, если смотреть изнутри, как там на самом деле? Есть говнокод? :) (Который вопреки общей продуманности все-таки возник из-за того что «ну вот так вот здесь получилось» и «сроки-форс-мажоры», и который в итоге так и остался на проекте потому что «итак вобщем-то работает, а исправить и сделать красиво — дорого, когда-нибудь потом может быть...»).
Да с этим вообще никаких проблем – конечно там море говнокода! Да мы даже с определенного момента тесты перестали писать. Да, не успевали, да, зашивались – но разве это оправдание? Естественно всё очень быстро превратилось местами в какашку. Добрые люди в Github даже придумали соответствующий смайлик, которым у нас любят пользоваться, по назначению: 
Нет такого «я собой доволен». Нам не дали там сделать то, что мы хотели. Но дали шанс в Ведомостях, за что спасибо.
Нет такого «я собой доволен». Нам не дали там сделать то, что мы хотели. Но дали шанс в Ведомостях, за что спасибо.
> Старайтесь по возможности предпочесть простой код магическим заклинаниям.
Не в бровь, а в глаз!
Не в бровь, а в глаз!
UFO just landed and posted this here
В начале тоже так думали. Но нет.
В Ленте на фронте вообще только MongoDB была со своим драйвером, в CMS sql база.
В Ведомостях модели одной и той же сущности разнятся в функциональном плане. Они вообще ориентируются на использование разных атрибутов. В JSON поле сущности хранится сериализованный вид модели, который тупо отдаётся дальше. Никаких динамических атрибутов, никакой логики.
В Ленте на фронте вообще только MongoDB была со своим драйвером, в CMS sql база.
В Ведомостях модели одной и той же сущности разнятся в функциональном плане. Они вообще ориентируются на использование разных атрибутов. В JSON поле сущности хранится сериализованный вид модели, который тупо отдаётся дальше. Никаких динамических атрибутов, никакой логики.
UFO just landed and posted this here
Вы ничего не написали про поиск, и странно, что никто про это не спросил. А было бы интересно, как он реализован?
Медиа контент это так же аудио и видео. Работу по конвертации ролика в разное качество лучше возложить на профессиональную видео-платформу.
А почему ffmpeg/avconv не хватило?
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Спасибо, практичная информация.
Не смотрели на open gov проект?
alphagov.github.io
github.com/alphagov
Мне кажется у них тоже интересный опыт — развернуть инфраструктуру для системы публикации британского правительства.
Не смотрели на open gov проект?
alphagov.github.io
github.com/alphagov
Мне кажется у них тоже интересный опыт — развернуть инфраструктуру для системы публикации британского правительства.
Спасибо, очень интересно! Вспоминаю как мы перезапускали actualidad.rt.com/ переводили с Perl на Python (Pylons+Postgres).
Второй раз сейчас занимаюсь перезапуском.
Хотелось бы почитать такой же отчет с с точки зрения выпускающих редакторов, главредов, а не только технарей.
Хотелось бы почитать такой же отчет с с точки зрения выпускающих редакторов, главредов, а не только технарей.
>Исправление опечаток на сайте выходит с задержкой меньше минуты.
А почему не сделать, чтобы материал удаляется из кэша, только когда он изменяется? Тогда задержек вообще не будет
А почему не сделать, чтобы материал удаляется из кэша, только когда он изменяется? Тогда задержек вообще не будет
Во-первых правильнее будет тогда уж делать не удаление из кэша, а обновление.
Во-вторых реализация такой системы немного сложнее. Необходимо формировать очередь на события обновления материалов. И в фоне уже делать запросы на обновление. Тут надо смотреть, на чьей стороне реализован кэш, в каком формате данные, как формируется ключ.
В-третьих есть риск слишком частого обновления страницы (например главной). Тогда надо либо делать таймауты, либо разбивать страницу на SSI инклуды, либо… В общем некая логика, которая забоится о достойном соотношении «отдать из кэша/заново сформировать контент».
Итого имеем: простая система с временем обновления до минуты; сложная система, с обновлением за секунды. Так как минуты – допустимое значение даже для сверх срочных новостей, то рациональным решением является выбор первого варианта.
Во-вторых реализация такой системы немного сложнее. Необходимо формировать очередь на события обновления материалов. И в фоне уже делать запросы на обновление. Тут надо смотреть, на чьей стороне реализован кэш, в каком формате данные, как формируется ключ.
В-третьих есть риск слишком частого обновления страницы (например главной). Тогда надо либо делать таймауты, либо разбивать страницу на SSI инклуды, либо… В общем некая логика, которая забоится о достойном соотношении «отдать из кэша/заново сформировать контент».
Итого имеем: простая система с временем обновления до минуты; сложная система, с обновлением за секунды. Так как минуты – допустимое значение даже для сверх срочных новостей, то рациональным решением является выбор первого варианта.
11 человек на фото — достаточно много.
В чем прикол? Количество человек больше чем количество шаблонов вывода lenta.ru
В чем прикол? Количество человек больше чем количество шаблонов вывода lenta.ru
UFO just landed and posted this here
Sign up to leave a comment.
Перезапуск медиа издания: обзор