Comments 84
Отличный разбор Гемфайла.
Как правило, CMS издательской системы предполагает изменение статусов публикаций. Часто, у издателей есть особые пожелания на этот счет. Соответственно, используются некоторые известные решения.
Правильно я понимаю, что в вашей CMS очень простая система статусов, вида — Черновик/Опубликовано?
Правильно я понимаю, что в вашей CMS очень простая система статусов, вида — Черновик/Опубликовано?
В прошлой было несколько статусов, но без state machine.
Сейчас сделали ещё проще, как вы и сказали, черновик/опубликовано.
Все дополнительные статусы нужны только для организации редакционного процесса. Как то «не выдана», «выдана редактору», «завершена», «вычитана», «окартинено»… Соответственно есть некоторый набор списков заметок, сгруппированных по определенным признакам, в том числе подобным состояниям. В зависимости от сценария, заметки перетекают из одного потока в другой.
Сейчас сделали ещё проще, как вы и сказали, черновик/опубликовано.
Все дополнительные статусы нужны только для организации редакционного процесса. Как то «не выдана», «выдана редактору», «завершена», «вычитана», «окартинено»… Соответственно есть некоторый набор списков заметок, сгруппированных по определенным признакам, в том числе подобным состояниям. В зависимости от сценария, заметки перетекают из одного потока в другой.
спасибо. Суть понятна
И еще пару вопросов, если позволите
1) Не нашел ничего связанного с поиском (мог пропустить). Не очень понятно, как устроен поиск по массиву данных, когда авторам нужно найти уже существующую статью (для правки, например, или сослаться на конкретный адрес старой публикации). Используется ли что-то для поиска?
2) как вы формируете слаги (ЧПУ)? я так понимаю генерировать их вам не приходится? Не читаю ленту, но по всей видимости там числовые ID в урлах.
3) Вопрос вне контекста тех. инструментария.
Если ли трудности при расчете релевантного контента для каждой публикуемой статьи. Я про блоки с названиями вроде: Читайте так же; По этой теме;
Понимаю, что если процесс расчета релевантного контента содержит какие-то специальные решения — то вряд ли вы расскажете об этом подробно, но если «магических» формул там нет, то было бы интересно узнать в будущих статьях ход решения общих для издательских систем вопросов.
PS: если вы планируете и дальше освещать вопросы устройства издательских систем, то обещаю быть одним из самых преданных ваших читателей, т.к. именно этим целенаправленно занимаюсь несколько последних лет. За поднятую тему огромное спасибо!
И еще пару вопросов, если позволите
1) Не нашел ничего связанного с поиском (мог пропустить). Не очень понятно, как устроен поиск по массиву данных, когда авторам нужно найти уже существующую статью (для правки, например, или сослаться на конкретный адрес старой публикации). Используется ли что-то для поиска?
2) как вы формируете слаги (ЧПУ)? я так понимаю генерировать их вам не приходится? Не читаю ленту, но по всей видимости там числовые ID в урлах.
3) Вопрос вне контекста тех. инструментария.
Если ли трудности при расчете релевантного контента для каждой публикуемой статьи. Я про блоки с названиями вроде: Читайте так же; По этой теме;
Понимаю, что если процесс расчета релевантного контента содержит какие-то специальные решения — то вряд ли вы расскажете об этом подробно, но если «магических» формул там нет, то было бы интересно узнать в будущих статьях ход решения общих для издательских систем вопросов.
PS: если вы планируете и дальше освещать вопросы устройства издательских систем, то обещаю быть одним из самых преданных ваших читателей, т.к. именно этим целенаправленно занимаюсь несколько последних лет. За поднятую тему огромное спасибо!
Поиск
Для реализации поска в Ленте использовался внутренний поиск Рамблера, который в свою очередь организован на Sphinx. Раз в N минут к нам приходит запрос от поисковика за обновленными записями для индексации. Чтобы найти материал мы через HTTP обращаемся к поисковику и получаем JSON.
В Ведомостях сейчас стоит Sphinx, в разрабатываемой версии будет использоваться ElasticSearch. Отправка данных на индексацию будет реализована похожим способом.
Адрес страницы
URL каждой заметки делается человеко понятным. В Ленте он составляется как слаг типа материала, дата, слаг данной заметки (пишется руками редактором). Итого получается нечто
В новой версии Ведомостей для составления адреса используются слаг первой рубрики, слаг типа материала, дата, транслитерация заголовка. Как пример:
Если заметка будет опубликована, адрес страницы будет зафиксирован. Есть возможность создать ассоцииованный адрес, и сделать его основным. Это используется, если надо изменить рубрику, дату, или заголовок.
Релевантные материалы
Если блок связанных материалов (ссылки по теме) формируется строго руками. То в блоках «Читайте так же» материалы подбираются очень просто: самые свежие по заданному срезу. Например самые свежие в той же рубрике и теге, что и первый рубрика и тег материала. Никакие интеллектуальные системы здесь не нужны – это лишнее.
Для реализации поска в Ленте использовался внутренний поиск Рамблера, который в свою очередь организован на Sphinx. Раз в N минут к нам приходит запрос от поисковика за обновленными записями для индексации. Чтобы найти материал мы через HTTP обращаемся к поисковику и получаем JSON.
В Ведомостях сейчас стоит Sphinx, в разрабатываемой версии будет использоваться ElasticSearch. Отправка данных на индексацию будет реализована похожим способом.
Адрес страницы
URL каждой заметки делается человеко понятным. В Ленте он составляется как слаг типа материала, дата, слаг данной заметки (пишется руками редактором). Итого получается нечто
/news/2012/12/22/foobar/. Каждый элемент адреса редактор может скорректировать.В новой версии Ведомостей для составления адреса используются слаг первой рубрики, слаг типа материала, дата, транслитерация заголовка. Как пример:
/finance/news/2012/12/22/foo-bar/.Если заметка будет опубликована, адрес страницы будет зафиксирован. Есть возможность создать ассоцииованный адрес, и сделать его основным. Это используется, если надо изменить рубрику, дату, или заголовок.
Релевантные материалы
Если блок связанных материалов (ссылки по теме) формируется строго руками. То в блоках «Читайте так же» материалы подбираются очень просто: самые свежие по заданному срезу. Например самые свежие в той же рубрике и теге, что и первый рубрика и тег материала. Никакие интеллектуальные системы здесь не нужны – это лишнее.
Жизнь показывает, что чем система статусов проще — тем проще и быстрее редакторам управлять сайтом. Другое дело, что у публикаций есть другие признаки, которые не «статус», а, например, наличие картинки или ожидание действия бильд-редактора, на какого редактора эта публикация «назначена», есть ли у неё ссылки, всякие галочки вкл/выкл рекламы/коментов.
спасибо.
> наличие картинки или ожидание действия бильд-редактора
Фактически, это может быть таким же важным признаком публикации, как и сам статус публикации. И потому, особенно интересно какова ваша практика управления состояниями публикации, т.к. это один из самых интересных организационных вопросов (по крайней мере для меня лично).
> наличие картинки или ожидание действия бильд-редактора
Фактически, это может быть таким же важным признаком публикации, как и сам статус публикации. И потому, особенно интересно какова ваша практика управления состояниями публикации, т.к. это один из самых интересных организационных вопросов (по крайней мере для меня лично).
Весело, конечно, и гемы хорошие :) Несколько новых для себя нашел, попробую. Но, жаль, что не везде полностью описываете выбор. И консерватизм смущает :)
А вас не смущает неиллюзорный шанс получить глюки системы, которые непросто отловить, но которых хватит для порчи репутации проекта?
Нет задачи обходить стороной нестандартные решения. Практиковаться можно на мелких проектах.
Нет задачи обходить стороной нестандартные решения. Практиковаться можно на мелких проектах.
Больше всего непонятно недоверие к потокам. С хттп-сервером и очередями понятно — если есть ресурсы (память), можно и старые проверенные решения использовать на MRI.
Вот Eventmachine вместо потоков — усложнение, по-моему. Извините, пожалуйста, если я задачу не понял правильно. По описанию, потоки — в самый раз. И глюков меньше можно получить, чем от EM.
Просто хотел сказать, что потоки в ruby работают стабильно, у многих проверены в продакшене.
Вот Eventmachine вместо потоков — усложнение, по-моему. Извините, пожалуйста, если я задачу не понял правильно. По описанию, потоки — в самый раз. И глюков меньше можно получить, чем от EM.
Просто хотел сказать, что потоки в ruby работают стабильно, у многих проверены в продакшене.
В том контексте EM была как раз кстати. Демон большую часть времени ничего не делал. Ждал когда в очереди появится заявка, скачивал файл. Заявок было немного, а время реакции внешних ресурсов – велико.
Когда практика большиства, в вопросе использования потоков, будет распространена – мы тоже до этого дойдём в основных задачах.
Когда практика большиства, в вопросе использования потоков, будет распространена – мы тоже до этого дойдём в основных задачах.
Очень круто, спасибо. По традиции, пара вопросов=)
1. Какие впечатления от Devise? У меня получалось, что он экономит немного времени при старте, но съедает кучу потом, когда гнешь его под свое приложение.
2. Была какая-то причина, по которой не использовались гемы типа simple_form/formtastic?
1. Какие впечатления от Devise? У меня получалось, что он экономит немного времени при старте, но съедает кучу потом, когда гнешь его под свое приложение.
2. Была какая-то причина, по которой не использовались гемы типа simple_form/formtastic?
1. Нормально, в Ленте нам хватало, расширяться особо не было нужды.
Но теперь в Ведомостях, сразу начали без него. Нам немного надо, но с какой-то бизнес логикой. Поэтому велосипед.
Про simple_form сейчас kSavelyev ответит.
Но теперь в Ведомостях, сразу начали без него. Нам немного надо, но с какой-то бизнес логикой. Поэтому велосипед.
Про simple_form сейчас kSavelyev ответит.
Мы пробовали оба гема для общего развития, они нам не пригодились. В админке формы не связаны напрямую с моделями, там one-page приложение на Бекбоне или Ангуляре, поэтому гемы не особо актуальны. На самом сайте же формы простые, 2-3 поля для регистрации или подписки, их можно сделать руками.
потокобезопасности MRI-интерпретатора
В каком смысле? Чем он может быть потоконебезопасен? Имелось в виду, что Rails или какой-нибудь middleware не до конца потокобезопасен?
Почему для api не взяли grape? И вас самих не коробит «фарадай»?
grape пробовали, не очень понравился. В одном новом API-сервисе использовали lotusrb, впечатления положительные.А что не так с
faraday?Впервые недавно столкнулся с puma. Если при phazed-restart pumactl отдаёт код возврата 0, но при этом сам перезапуск воркеров может пройти неудачно, и оставить сервер в состоянии 502. Не понимаю, кто может это любить. Под JRuby есть и более родные сервера.
terminal-notifier-guard
Под linux guard умеет использовать inotify без доп. гемов.
Зачем вы рекомендуете Compass? Там старые данные, нужно самому помнить, где писать примесь, а где нет. Многих префиксов просто нет.
Единсвенный способ работать с префиксами сейчас — это Автопрефиксер, у которого есть гем autoprefixer-rails.
У него самые свежие данные по префиксам с Can I Use. Во-вторых, он в пару раз быстрее. В-третьих, он парсит CSS и сам находит префиксы в свойствах, селекторах (
Сейчас нет ни одной причины использовать Compass.
Единсвенный способ работать с префиксами сейчас — это Автопрефиксер, у которого есть гем autoprefixer-rails.
У него самые свежие данные по префиксам с Can I Use. Во-вторых, он в пару раз быстрее. В-третьих, он парсит CSS и сам находит префиксы в свойствах, селекторах (
:fullscreen, например) и значениях (calc()).Сейчас нет ни одной причины использовать Compass.
Вы автор этой утилиты?
Я. Но не только я считаю, что Compass устарел. Google рекомендует именно Автопрефиксер и не упоминает Compass. GitHub хочет уйти к Автопрефиксеру. Яндекс, Google и Mail.ru уже используют Автопрефиксер. Twitter полностью перешёл только на Автопрефиксер (отказались даже от Sass в пользу постпроцессоров типа Rework и PostCSS). Bootstrap и Wordpress тоже собираются с помощью Автопрефиксера, выкинув Compass.
UFO just landed and posted this here
Да, взвалили всё это на администратора.
Медленнее стало субъективно. Они ж ничего не замеряли! Там не всё отлажено. Например скачем между LXC vs Docker. Финализируем – расскажем.
Медленнее стало субъективно. Они ж ничего не замеряли! Там не всё отлажено. Например скачем между LXC vs Docker. Финализируем – расскажем.
Отличная подборка, ребят. Спасибо огромное. Красавчики :)
Еще вопрос назрел — а как решали проблему индексирования гуглом и яндексом?
Я так понял, что весь контент отдаётся в JSON и дальше ангулар работает с ним и с шаблонами
Я так понял, что весь контент отдаётся в JSON и дальше ангулар работает с ним и с шаблонами
Так работает система управления контентом. Фронтенд работает классически с серверной генерацией HTML.
круто! а дублирования кода не возникает, тк шаблоны и вообще страницы разные совсем, верно понимаю?
Тут два разных приложения — в одном живут рубишные модели с бизнес логикой, Ангуляр или Бекбон и one-page приложение, в другом — система получения нужного JSON из закрытого API, и система трансформации этого JSON в то, что нужно в шаблоне и работа с конечным пользователем.
Поэтому дублирования нет, страницы абсолютно разные.
Поэтому дублирования нет, страницы абсолютно разные.
Спасибо за статью, открыл для себя кое-что новое. diffy точно возьму на вооружение.
Насчет faye — я использовал для нее обертку private_pub от Ryan Bates, там как раз содержатся некоторые фиксы безопасности. Пришлось немного допилить под свои нужды, но работа меня устраивала.
Насчет faye — я использовал для нее обертку private_pub от Ryan Bates, там как раз содержатся некоторые фиксы безопасности. Пришлось немного допилить под свои нужды, но работа меня устраивала.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
А тут просто. При разработке на локальной машине, ребята запускают веб приложения через Pow. Соответственно nginx с его настройками локально нет. В production стараемся делать это средствами nginx.
UFO just landed and posted this here
Так может подробно и опишите, как упростить локальное развертывание nginx? Например неплохо бы, чтобы у нас был доступен некий app.local который частично повторяет логику production конфигурации.
Vagrant для этого можно использовать. Пока сам не пробовал, хочу следующий проект с ним начать.
UFO just landed and posted this here
Вагрант, знаю, многие используют, но у нас он не прижился. Как-то слишком на любителя. В основном потому, что команда наша очень компактная, нет недостатка в серверах и нет необходимости поднимать продакшн-окружение локально.
UFO just landed and posted this here
UFO just landed and posted this here
Я так понимаю, Vagrant позиционирует себя как инструмент для разработчиков, а не админов.
С его помощью можно запустить одну или несколько виртуалок и настроить их с помощью средств для деплоймента (chef/puppet/ansible/руки).
Мне кажется, это — хороший вариант «как упростить локальное развертывание nginx».
VBoxManage CLI не смотрел. С ним можно закомитить в гит файл в небольшой, чтобы потом каждый мог запустить у себя ВМ?
С его помощью можно запустить одну или несколько виртуалок и настроить их с помощью средств для деплоймента (chef/puppet/ansible/руки).
Мне кажется, это — хороший вариант «как упростить локальное развертывание nginx».
VBoxManage CLI не смотрел. С ним можно закомитить в гит файл в небольшой, чтобы потом каждый мог запустить у себя ВМ?
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Частенько бывает, что при исправлении ошибок не происходит обновления зависимостей, например, если actionview 4.1.7 зависит от builder, то при переходе на 4.1.8 версия builder у вас не обновится, если исправление каких-то ошибок не связано с исправлением ошибок в builder.
Откуда у вас такой плохой опыт?
Откуда у вас такой плохой опыт?
Ребята спасибо за классную статью и подачу материала.
Кто бы мог подумать в далеком 2006, что неизвестный язык руби дойдет до таких высот)
Кто бы мог подумать в далеком 2006, что неизвестный язык руби дойдет до таких высот)
В последнее время всё больше вижу что люди стараются использовать puma вместо unicorn на MRI. Сюдя по тестам unicorn значительно быстрее.
Ребят, это в хаб Rails тоже надо срочно ))) Статья высочайшего класса.
На самом деле в rails-api особого смысла нет, тк по быстродействию оно практически не отличается от просто рельсы — что-то порядка пары процентов. Тот же не полюбившийся вам grape с ar дает 20+ процентов прироста, совсем брутальный вариант sinatra/ar/oj и ловкость рук может дать больше 30.
Puma vs unicorn. Выше пишут, что значительно быстрее, но я не смог увидеть существенной разницы, особенно если за ними рельса ходит в базу и генерит вьюшки, на что уходит 95% времени ответа и разницу можно увидеть только если там синатра отдает что-то из редиса например. Зато пума может дать большой выигрыш по памяти, например 40%, при той же производительности и если у вас с десяток апп серверов и за хостинг с памятью вы платите из своего кармана, то пума начинает нравится намного больше )
Puma vs unicorn. Выше пишут, что значительно быстрее, но я не смог увидеть существенной разницы, особенно если за ними рельса ходит в базу и генерит вьюшки, на что уходит 95% времени ответа и разницу можно увидеть только если там синатра отдает что-то из редиса например. Зато пума может дать большой выигрыш по памяти, например 40%, при той же производительности и если у вас с десяток апп серверов и за хостинг с памятью вы платите из своего кармана, то пума начинает нравится намного больше )
Ruby кажется вкусным, надо попробовать.
А чем не угодил стандартный метод truncate?
gem 'truncate_html'
Меня очень интересует вопрос писали ли вы сырой SQL или обходились возможностями ORM? Особенно учитывая что в жизни проекта был переход с MySQL на PostgreSQL. Этот переход был как «drop-in replacement» (благодаря высокому уровню абстракции ActiveRecord) или всё же пришлось переписать тонну платформо-зависимого кода с одной БД на другую?
Раньше не писали. Возможностей ORM хватало с головой. Позже стало ещё проще – старались делать запросы попроще. Самой большой проблемой при смене базы данных была миграция сами данных. Вроде полно скриптов, которые должны облегчить жизнь, но на практике пришлось повозиться. Кроме того был момент: приостанавливать работу редакции или нет. Решили, что проще для всех, если мы на некоторое время остановим редакцию, нежели будем делать realtime репликацию-миграцию или доливать изменения.
Сейчас ситуация хуже. Из-за активного использования в PostgreSQL таких структур данных, как array, hstore, json, приходится писать raw sql, в основном для выражений
Сейчас ситуация хуже. Из-за активного использования в PostgreSQL таких структур данных, как array, hstore, json, приходится писать raw sql, в основном для выражений
where. Одна из проблем ActiveRecord. Добавим до кучи жёсткую привязку всегда иметь поле id primary key – с любой нестандартной схемой начинаются танцы. Посматривали на Sequel, но пока не решились.UFO just landed and posted this here
А эти структуры никак не связаны с масштабированием. Массив служит для упрощения организации ассоциативных связей. hstore удобен для динамических атрибутов объекта. А json для кэшированных структур данных. Валидации на уровне обработчиков в приложении. Разумеется триггеры и хранимые процедуры не используем, всё концентрируется в приложении.
А глобально проблемы с масштабированием в такого рода проекта просто нет. Нет такого объёма данных, который не уместится на одном сервере. Нет такого кол-ва запросов, которые нельзя размазать по мастер-слейв.
А глобально проблемы с масштабированием в такого рода проекта просто нет. Нет такого объёма данных, который не уместится на одном сервере. Нет такого кол-ва запросов, которые нельзя размазать по мастер-слейв.
Sign up to leave a comment.
Набор Ruby библиотек для CMS и сайта медиа издания