25 ноября 2014 в 09:18

Перезапуск медиа издания: обзор



Мне довелось поработать (fb) в интернет издании Лента.ру. Пройти путь от разработчика до технического директора. Успешно реализовать полноценный перезапуск. Попутно занимаясь подобными проектами меньшего масштаба. Теперь мы с командой занимаемся подготовкой перезапуска интернет газеты Ведомости (fb).

Расскажу о разработке проектов медиа изданий. Галопом по Европам, зацепимся за основные темы. К вам, дорогие читатели, просьба набросать вопросы, которые необходимо раскрыть более детально. Например мой коллега планирует написать о развёртывании системы, отказоустойчивой схеме работы сайта.



Технологии


Один из вопросов, который интересует руководство издания – на каком языке будет вестись разработка. Возникает вопрос сугубо из практических соображений – стоимость разработчиков. Ответы на этот вопрос довольно просты.

Во-первых, выбор языка основывается на том, как хорошо его знают ведущие разработчики. Если у вас есть разработчики, и они владеют языком А, то глупо требовать от них знания языка Б. Заменить ведущих разработчиков – задача не простая.

Во-вторых, есть на рынке популярные языки: PHP, Python, Ruby и остальные, менее популярные. Есть некоторое заблуждение, что одни, дешевле других, или разработчиков одного языка, проще найти, чем разработчиков другого. Заблуждение в том, что измерить уровень профессионализма между разработчиками разных языков очень сложно. Всё становится запутанным, когда сравнивают опыт и желаемое вознаграждение каждого. В результате имеем: подходящего разработчика одинаково сложно найти для любого языка программирования. Их либо много, но все они низкой квалификации, или они много просят, или они специалисты другого профиля и т.д.

Есть ещё один фактор в выборе платформы для разработки. Обычно издания входят в состав какого-то немаленького холдинга. И в зависимости от степени развитости корпоративной культуры, изданию будет навязываться соответствующее решение.

В своё время Лента.ру переходила с Perl на Ruby, тогда как в Рамблере практиковали Python. Сейчас Ведомости переходят с PHP на Ruby, при этом PHP нам не навязывали.

Выбор сопутствующих инструментов, таких как операционная система или база данных, обычно никого не волнует.

В конечном счёте для издания не важно на каком языке будет написан проект, какие библиотеки и сервисы он будет использовать. Важнее, что команда, которая делает проект, владеет инструментом на профессиональном уровне.

Постановка задачи


Процесс полного перезапуска — дело долгое. Но это не повод расслабляться в начале, и работать на пределе под конец. Руководители определяются с целями, которые они хотят достичь, задачами, которые хотят решить. Коллективы редакций – это десятки людей. А численность всего штата издания легко может перевалить за сотню. Если перезапуск подразумевает существенные изменения, это значит что очень большому количеству людей нужно будет изменить подход к работе.

Чтобы сделать что-то хорошее, нужно абстрагироваться от текущего состояния, смоделировать идеальный мир, и уже после этого, строить стратегию перехода из одного состояния в другое. Иначе можно топтаться вокруг старого колодца. Эту задачу решает главный редактор и руководство издания. Анализируя статистику, изучая лучшие практики и ставя перед собой амбициозные цели, они формируют концепцию.

В результате дизайнеры получают задачу визуализации нового лица издания. Разработчики продумывают стратегию воплощения идеи. Сложность задачи в том, что помимо прочего необходимо создать инструмент каждому отделу – редакции, маркетингу, службе поддержки. То есть, помимо создания публичного сайта в разном представлении, нужно создать систему управления для редакции, коммерческого отдела, службы маркетинга и поддержки.

Реальность такова, что в публичном сайте будет продумана каждая деталь главным редактором и прорисована дизайнером. Создание систем управления контентом частенько даётся на откуп разработчикам. Тут конечно не полная самодеятельность: сбор требований, описание сценариев работы – всё в лучших традициях умных книжек. Но простора для фантазий очень много.

Пазл


При создании проекта медиа издания удобно строить сервис-ориентированную архитектуру. Это позволят заниматься параллельной разработкой независимых частей проекта. Главное иметь общую картину и зафиксировать интерфейс взаимодействия между сервисами. Компоненты системы могут использовать общий код, обращаться друг к другу по какому-то протоколу поверх TCP соединения, использовать общее хранилище данных.

Публичный сайт практически всегда стоит отделить от всех внутренних сервисов. Для работы сайта нужно приложение генерации HTML страниц или JSON для API. В зависимости от архитектуры проекта, приложение может напрямую соединяться с классической базой данных (MySQL, PostgreSQL, MongoDB…) или же использовать сервис прослойку. Такое приложение можно легко масштабировать. Все внутренние сервисы, в том числе системы управления контентом, можно закрыть по IP адресам, что добавляет плюс в пользу безопасности.

Выбор базы данных основывается на том, какие структуры данных вам необходимо хранить и извлекать.

Например в Ленте.ру для публичного сайта мы использовали MongoDB. Нам нужно было получать документы со сложной древовидной структурой. При этом основной базой данных у нас была MySQL (позже мигрировали на PostgreSQL). В основной базе всё хранилось в нормализованном виде. В MongoDB данные были в удобном для использования виде. Для синхронизации между базами мы использовали фоновый сервис, который следил за изменившимися данными, формировал для них новое представление и записывал в MongoDB. Сервис основывался на очереди в Redis, куда попадали сообщения об изменениях.

В случае с Ведомостями мы пошли иным путём. В PostgreSQL помимо классических структур данных, есть внутренние типы: array, hstore, jsonb. Благодаря им можно упростить хранение связей между ассоциированными сущностями, динамические атрибуты, сложных древовидных структур. Таким образом мы получаем в лице одного сервиса нормализованные данные, при это они представлены в удобном для публичного сайта виде, конечно с некоторым компромиссом по отношению к MongoDB.

Система управления редакционным контентом (CMS) является основным инструментом редакции. С её помощью создаётся контент. Осуществляется управление и организация редакционным процессом. Формируется картина дня на публичном сайте. С публичным сайтом они делят только базу данных. Это самостоятельное приложение, доступ к которому осуществляется только через авторизацию. Ещё лучше, если доступ ограничен определенным списком IP адресов. Именно с этой системы начинается разработка проекта.

К сервису сбора статистики предъявляются особенные требования по производительности. Для начала ответим на вопрос: “зачем он нужен?”. Частенько редакции необходимо собрать статистические данные в разрезе параметров, которых нет в сторонних сервисах. Например в Ведомостях практикуется доступ по подписке. Соответственно есть запрос на сбор данных определенной группы пользователей. Информацию о статусе подписки сторонним сервисам мы не передаём. При этом нам нет необходимости строить полноценную замену открытым метрикам. Только минимальный функционал, покрывающий запросы аналитиков.

Такой сервис так же разбивается на компоненты: сбор событий в промежуточную очередь, обработка и запись в нормализованную базу данных, выборка агрегированных данных. Для двух первых компонент мы используем Golang, для промежуточной очереди – Redis, для нормализованных данных – PostgreSQL, для выборки агрегированных данных – Ruby.

Сервис хранения медиа контента так же вынесен в независимое приложение. В его задачи входит принять файл, сохранить его на диск, вернуть структуру данных, описывающую необходимую мета информацию: путь, размер, тип. Если мы работаем с изображениями, то сервис должен заниматься генерацией разных по геометрическим размерам версий. Некий аналог описывался в хабра статье. Касательно медиа контента есть несколько моментов.

Первый – управление доступностью к определенным файлам. Вы можете опубликовать заметку, в которой используются какие-то изображения. В один прекрасный момент вам может понадобиться скрыть изображение по ссылке, но не удалять его из внутреннего фото-банка. В Ленте мы использовали символьные ссылки. Если файл публичный – для него создавалась ссылка. Если файл надо скрыть, в том числе при скрытии связанной заметки, удалялась символьная ссылка. В Ведомостях разделение на публичные и закрытые изображение реализуется через права доступа к файлам.

Второй – сеть доставки контента. Когда то в Ленте видео пользователям раздавали прямо со своих серверов. И вот настал момент, когда показом интересного ролика в хорошем качестве мы забили свой гигабит, и наш сайт начал тормозить. Само собой правильное решение – использовать CDN, благо сегодня это вполне доступная по цене услуга. В качестве теста одно время мы использовали сторонний CDN сервис и для статических изображений. Но в данном вопросе практическая польза оценивалась слишком дорого, и финансисты нам отказали в таком удовольствии.

Третий – масштабирование изображений. В зависимости от контекста использования изображения масштабируют в несколько версий. Специфика медиа изданий подразумевает, что есть отдельный человек – бильд редактор, который следит за тем, какими получились изображения в результате ресайза и кропа. И если ему что-то не нравится, у него должен быть инструмент, который позволяет заменить определенную версию изображения. Иначе вы в фото-галерее “Мисс Мира” в превью версиях можете получить изображения дам с отрезанными головами.

Медиа контент это так же аудио и видео. Работу по конвертации ролика в разное качество лучше возложить на профессиональную видео-платформу.

Полезно иметь отдельный сервис авторизации для пользователей сайта. Часто он тесно связан с системой комментирования.

Процесс разработки


Ранее я писал, что нужно уделить должное внимание проектированию. При это нужно не бояться писать код. Невозможно предусмотреть всё, сделать хорошую систему с чистого листа. Нужно итерационно развивать систему. Написали задуманный функционал, проанализировали, будьте готовы переписать вновь. Это нормально. Время, которое вы тратите на написание кода много меньше того, которое тратите на обдумывание. Ваш код не высечен на скале.

Короткий абзац: системы контроля версий. Почему-то ещё актуально акцентировать на этом внимание.

Современный подход в разработке предполагает написание тестов. Сложность в том, что в изданиях с наследием у руководителей сложилось некое представление о скорости разработки. И тут приходите вы, с модными технологиями, девизом, что сейчас станет проще. А в результате похожие задачи делаются либо такое же время как и раньше, а то и дольше. Вы понимаете, что тесты – дело благое, и пытаетесь донести эту истину главному редактору. Скорее всего у вас ничего не получится. Редакции нужен продукт, а тесты нужны разработчикам. То, что для качества продукта нужно тратить время на написание тестов – просто данность.

Не изменяйте своё рабочее окружение в активной фазе очередного этапа разработки. С выходом обновлений операционной системы у разработчиков, любителей быть на острие волны новых версий, частенько может потеряться день другой. Это как здоровье солдата в армии. Вы нужны в работоспособном состоянии, ваша рабочая станция не должна выходить из строя, только потому, что вчера вышла новая версия вашей любимой ОС.

Немного странного. Помимо основной деятельности нужно находить время на работу по сторонним проектам. С коварной целью: обкатывать новые технологии и практики. Не всегда есть возможность использовать в боевой системе различные интересные решения. Делайте это в небольших сторонних проектах.

Динамические языки программирования позволяют широко использовать метапрограммирование. Это может существенно усложнить жизнь в будущем как вам, так и вашим коллегам. Старайтесь по возможности предпочесть простой код магическим заклинаниям.

Мониторинг и профилирование


Редакция использует различные метрики для анализа успешности своей деятельности. Разработчики должны заранее позаботиться об инструментах профилирования и мониторинга своих приложений. Это очень опасное занятие – запускать систему без отслеживания состояния. Речь не только о показателях потребления оперативной памяти и процессорного времени. Для создания хорошего приложения необходимо отслеживать весь стек выполнения программы. Потратьте время на настройку такого окружения.

Выборки из базы данных могут меняться по мере изменения требований к проекту. И снова профилирование приходит на помощь – вы быстро узнаете, что нужно оптимизировать.

Подготовьте к нагрузочному тестированию данные, максимально приближенные к реальным. Запустите тестирование на длительный период времени и изучите слабые стороны вашего приложения.

Процесс переезда


Переезд со старой платформы на новую завязан на редакции и архиве. Редакция должна перестроить свою процессы, освоиться в новой системе управления контентом. перенос архива должен быть с сохранением ссылочной целостности.

Для редакции есть три этапа. На первом этапе они тестируют CMS в свободном режиме. В это время может что-то ломаться, по требованию изменяться. Второй этап начинается после чистового импорта всего контента в новую платформу. При этом новый сайт ещё публично не доступен. Редакция работает в двух системах – старой и новой. Связано это с тем, что чаще всего нет обратной совместимости в структуре старого и нового контента. Обычно этот период длится неделю. И уже с момента публичного перезапуска наступает третий этап, когда все счастливы, редакция работает на новой платформе. Старый сайт прекращает свою работу.

Переезд архива готовится довольно длительное время. С каждым прогоном импорта возникают некоторые баги, после исправления которых импорт начинается с начала. У заметок может измениться адресация. При этом хорошим тоном считается, чтобы переходы по старым ссылкам инициировали редирект на новый адрес. Чтобы это реализовать, нужно заранее готовить таблицу маршрутизации. Она понадобится и в будущем. Бывают ситуации, когда необходимо изменить адрес страницы, при этом надо, чтобы переходы по старому адресу также приводили к редиректу на новый. Вы просто делаете у заметки список ассоциированных адресов, один из которых маркируется как главный.

Мобильная версия


Мы совершили ошибку, пусть и вынужденную, когда перезапускали Ленту.ру без браузерной мобильной версии сайта. Но это был осознанный риск, и мы оперативно исправились, кроме того выпустили аж две версии – pda и mobile. Первая была предназначена для старых телефонов, с минимумом изображений. Такие телефоны мы называли “алконокия”. Вторая для смартфонов с большими дисплеями, аля сами знаете что. Со временем мы стали акцентировать внимание на мобильной версии, реализовав автоматический редирект с десктопной версии.

Помимо реализации автоматического редиректа, мы реализовали возможность запоминать выбор версии. То есть, если вы зашли с телефона, вас перекинуло на мобильную версию, а вам оно не надо, вы выбираете десктопную. Теперь при каждом следующем заходе вас никуда автоматически не отправят.

Так же неплохо показать пользователю сообщение о том, что мы его автоматически перенаправили на другую версию.

Эту логику мы реализовали на стороне nginx. С помощью страшного регулярного выражения определялся тип устройства – мобильное или нет и выставляли флаг $ismobile = 1. Смотрели на значение cookie с именем view_version, которая определяла сохраненное значение о предпочитаемой версии. При первом заходе на сайт это значение не определено. Ниже пример кода, который определял, делать редирект или нет:
if ( $ismobile = 1) { set $mobile_rewrite 1;}
if ( $cookie_view_version = 'm' ) { set $mobile_rewrite 1; }
if ( $cookie_view_version = 'www' ) { set $mobile_rewrite 0; }

Соответственно, если значение переменной $mobile_rewrite равно единице, то делаем редирект на мобильную версию, попутно выставляя одноразовую cookie, которая служила триггером для отображения информационного сообщения.

Настройка сервисов


В продолжении конфигурации веб-сервера можно отметить несколько моментов. Пока основным протоколом передачи данных в вебе является HTTP/1.1, актуально использовать несколько доменов для раздачи статики. Если вы используете кастомные шрифты на сайте или делаете вызовы к API со страницы клиента, то не забывайте указывать корректные CORS заголовки в настройках соответствующего веб-сервера.

При построение сервисно-ориентированной архитектуры может получиться, что некоторые ваши внутренние сервисы не защищены авторизацией приложения. Как пример – отдельный сервис загрузки изображений. Доступ к нему должны иметь только авторизованные редакторы. При этом у вас есть отдельный сервис авторизации для тех же редакторов. Сервис авторизации примитивен – получает заголовки, и отвечает положительно или отрицательно. С помощью модуля ngx_http_auth_request_module мы можем на каждый запрос к сервису загрузки изображений делать подзапрос к сервису авторизации. Живой пример конфигурации можно посмотреть здесь.

There are only two hard things in Computer Science: cache invalidation and naming things.

— Phil Karlton


Для названия хостов на серверах в Ленте мы использовали марки сигарет. Для Ведомостей выбираем из названия звёздных систем. Приложениям имена выбирали среди видов птиц. Например петух у нас занимался генерацией статики в старых версиях. В Ведомостях талисманом выступает большая рыба – big fish. Акулы бизнеса.

Проекты медиа изданий в России не являются высоко-нагруженными. Последний пик посещаемости в Ленте весной был около 20 миллионов просмотров в сутки. Довольно просто построить систему, которая выдерживает такие нагрузки без кэширования. Мы практикуем таки использовать кэш, на короткий интервал времени – несколько десятков секунд. Это снимает с нас проблему инвалидации кэша. Исправление опечаток на сайте выходит с задержкой меньше минуты. При этом это позволяет использовать такую замечательную опцию в nginx, как proxy_cache_lock. Из десяти одинаковых запросов к веб-серверу, только один будет отправлен на бэкенд. Это позволяет равномерно распределить нагрузку на приложение.

Визуализация небольшой DDoS атаки:


Резервное копирование


Само собой нужно делать бэкапы данных. При этом удобно иметь горячий резерв и периодически выполняемый полный бэкап.

Горячий резерв спасёт вас, когда нужно восстановить максимально свежую версию данных. Самый простой способ – простая репликация в режиме реального времени.

В случае, если шальным движением из данных будет удалён важный кусок данных, восстановить часть из них можно из ежесуточного бэкапа.

Люди


Будьте внимательны. Со временем некоторые процессы превращаются в рутину. Естественным образом возникает желание автоматизировать что-то. По завершению очередного этапа разработки, оглядываешься назад, а руки уже чешутся сделать лучше. Надо стараться терпеливо разбираться в каждой ситуации. Останавливаться, пробовать по другому смотреть на свою работу. Может получиться, что те задачи, которые кажутся вам важными, таковыми не являются. И наоборот.

Планируйте свою работу. Уделяйте достаточно времени проектированию. Нет необходимости на скорую руку собирать прототип с помощью вашего любимого фреймворка только потому, что вам доставляет это удовольствие, и вы знаете, чем займётесь в ближайшие пару часов или дней. Не успеете оглянуться, а вы уже проделаете кучу работы, которую с большой вероятностью надо переделать или и вовсе выкинуть.

Будьте дружелюбны и терпеливы. Работая в коллективе, важно уметь общаться с коллегами. Чаще всего над проектом работает больше чем один человек. А это значит, что у вас будут формироваться отношения между коллегами. От того, насколько вы хорошо относитесь другу к другу, зависит результат всей ваше работы. Это и профессиональные, и личные отношения. Напряжение будет расти по мере приближения даты сдачи проекта. И слаженность работы команды зависит не только от Васи и Пети, но и от вас.

У вас в команде должен выработаться формат профессиональной коммуникации. Самый простой пример – постановка и выполнение задачи. Вы должны внятно формулировать задачи. Казалось бы, очевиднейший пункт. А всё равно грабли стабильно попадают в лицо. То, что у вас в голове есть мысль, не значит, что она летает и в голове коллеги. Задачу, пересказ которой занимает несколько минут, в два слова описать ну очень сложно. Старайтесь выразить свою мысль словами “на бумаге”. А вот уже после того, как коллега прочитает ваш опус – поговорите! Обсудите задачу, убедитесь, что вашу мысль правильно поняли. В обратную сторону принцип тот же. Если вы закончили задачу, расскажите про это. Вы себе не можете представить, сколько времени это вам сбережёт.

Позиционирование отдела


Хотелось бы немного отметить роль разработчиков в издании. Нужно понимать, что разработка по отношению к редакции – некий обслуживающий персонал. Наша задача – дать удобный инструмент. Недопустимо надменно относиться к редакторам, которые не понимают, почему вот так резко вместо связи “один к одному” нельзя сделать связь “один ко многим”. Ну загрузили они вместо картинки видео файл. Система не должна валиться с ошибками от некорректного пользовательского ввода. Если вы ждёте число, а вам прилетела строка – так значит сами виноваты, что допустили такое, а не редактор инвалид. Попробуйте за день написать десяток другой новостей без копи-паста, с анализом источников для подтверждения фактов.

Речь не о том, чтобы выполнять все прихоти редакции. Просто надо с терпением относиться к желаниям и хотелкам коллег – делаете ведь общее дело.

Итог


Перезапуск медиа издания мало чем отличается от других. Всё так же важна сплоченность команды. Вы должны быть на шаг впереди редакции, предугадывая тот новый функционал, который они захотят воплотить в жизнь. Проектируем – делаем, проектируем – переделываем. Чревато недооценивать роль мониторинга состояния серверов, приложения, клиентской части. После перезапуска приходится уделять много внимания анализу поведения вашей новой платформы. Доводите дело до конца.

С нетерпением будем ждать ваших вопросов, быть может для продолжения.
Заур Абасмирзоев @Kavkaz
карма
45,0
рейтинг 0,0
Похожие публикации
Самое читаемое Разработка

Комментарии (46)

  • +5
    Очень хотелось бы посмотреть, как выглядят CMS Ленты или Ведомостей, чтобы сравнить с тем, что я делаю для своей маленькой редакции :)
    • +9
      Про редакционную CMS отдельно расскажем, но это несколько позже.
    • 0
      А еще w-o-s.ru, кажись, собирались показывать свою.
  • +2
    Познавательно, спасибо.
  • +2
    сколько разработчиков и за какой срок создали всю эту систему? то есть, с момента написания первых строк кода и конфигов до первого импорта старой базы
    • +1
      Заложили первый кирпич в мае, но продумывать начали раньше.
      commit 0ab5de6d50afd9f112d6339f823c2c9f64206f44
      Author: Zaur Abasmirzoev <zaur.kavkaz@gmail.com>
      Date:   Tue May 22 12:14:59 2012 +0400
      
          init
      

      Количество разработчиков росло с двух, до пяти в момент перезапуска. Это именно ruby разработчики и веб технологи. Импорт готовился примерно месяц. За это время мы полным составом отвлекались на спецпроекты, в частности «Олимпиада-2012», которая была как тест-драйв. После чего много пришлось переделать. В сентябре начали заниматься и фронтендом.

      Жарко было последние полтора месяца до перезапуска. Переделка макетов, структуры. Снова переделывать админку, корректировать импорт, перевёрстывать сайт.

      Непросто было в следующий месяц – очень много битых ссылок. Даже после перезапуска мы узнавали новое о старом движке.

      • 0
        Спасибо!
        А как решили вопрос хранилища данных? Скажем, какой-то архив фотографий и материалов, которыми оперируют редакторы и журналисты до того, как выгружать это во фронтенд. Используется свой велосипед для планирования выпусков или готовые решения?
        • +1
          Эти задачи решает CMS. Некоторые инструменты для планирования редакционного процесса как раз позволяют заниматься организацией материалов. Медиа-банк как таковой не прижился. Если в журналах такой банк изображений актуален, то в интернет изданиях нет. Не так категорично конечно. Но как есть. Используются подписки на платные фото агенства. По запросу нужная заметка «окартинивается».
      • +1
        Очень интересная статья, и очень информативные комментарии. Помнится, был опыт переноса сайта, пусть и небольшого, с одной CMS на другую. Это был тот еще кошмар, и битые ссылки оказались одним из ужасов, ибо их было много, а сайт без перелинковки не представлял интереса. Пришлось руками править. А еще — картинки… Которые тоже почему-то конфликтовали местами с новой админкой… Поэтому такие статьи, как ваша, помогают понять, к чему готовиться, на чем акцентировать внимание.
        • +1
          Кстати – картинки. При их переносе мы так же сделали некую схему соответсвия. Так как для каждой публичной ссылки у нас была символьная ссылка (в статье описано почему), то это позволило делать ссылки со старого адреса картинки на новый. Тем самым мы сохранили и пути до картинок.
      • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Спасибо, очень информативно написано.
    Вопрос: какие гемы использовались в Ленте и используются сейчас в Ведомостях? Были гемы, которые не оправдывали себя в процессе разработки и заменялись самописным велосипедом?
    • +2
      Чтобы не получилось простого перечисления слов, мы попробуем ответ на Ваш вопрос оформить отдельной заметкой.

      Были разные ситуации. Какие-то библиотеки отпали после выхода rails 4, какие-то доставляли сюрпризов. У нас изменилась архитектура, скажем так существенно. Оттого состав гемов претерпел изменения.
    • +4
      • 0
        И еще раз спасибо, крайне оперативно и познавательно.
  • +2
    сдулась лента.ру
  • 0
    *сдублировал коммент случайно*
    • +1
      К моему сожалению ;) нет. Я кстати вообще против паролей!

      В совсем старой CMS Ленты был следующий принцип: заходим по общему (auth_basic) логин-паролю, выбираем редактора, с которым будет ассоциирован сеанс, и работаем! Доверие, господа.

      Без некоторого соглашения с редакцией об уровне доверия и возможностях трудно будет обеим сторонам. Например если вы редактору не позволяете использовать html теги, embed код, вставки js, которые легким движением могут превратиться в «трояна», то это ограничит его в форматах представления материала. А вас, как разработчика, на каждый такой сценарий заставит реализовать соответсвующий функционал.
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          В Ленте – нет. Зачем? Если редактор захочет навредить, есть более элегантные способы. Например был прецедент, когда редактор навставлял безобидных ссылок на свой сайт в начале своих заметок.

          А можно ещё написать слово-орган в заголовке, и изданию выдадут предупреждение!
  • 0
    А в этот раз вы не в плейн-тексте храните пароли для новой CMS? :D
  • +1
    Очень структурно и в целом познавательно, спасибо!

    Как и почти всегда при взгляде со стороны создается впечатление того, что под капотом проекта всё должно быть глянцево и вылизано при таком подходе (если опираться на то, что видно снаружи сайта, а также на тон и содержание повествования технического специалиста, написанного в стиле «я собой доволен»).
    Но положа руку на сердце, если смотреть изнутри, как там на самом деле? Есть говнокод? :) (Который вопреки общей продуманности все-таки возник из-за того что «ну вот так вот здесь получилось» и «сроки-форс-мажоры», и который в итоге так и остался на проекте потому что «итак вобщем-то работает, а исправить и сделать красиво — дорого, когда-нибудь потом может быть...»).
    • +6
      Да с этим вообще никаких проблем – конечно там море говнокода! Да мы даже с определенного момента тесты перестали писать. Да, не успевали, да, зашивались – но разве это оправдание? Естественно всё очень быстро превратилось местами в какашку. Добрые люди в Github даже придумали соответствующий смайлик, которым у нас любят пользоваться, по назначению:

      Нет такого «я собой доволен». Нам не дали там сделать то, что мы хотели. Но дали шанс в Ведомостях, за что спасибо.

      • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    > Старайтесь по возможности предпочесть простой код магическим заклинаниям.

    Не в бровь, а в глаз!

  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      В начале тоже так думали. Но нет.

      В Ленте на фронте вообще только MongoDB была со своим драйвером, в CMS sql база.

      В Ведомостях модели одной и той же сущности разнятся в функциональном плане. Они вообще ориентируются на использование разных атрибутов. В JSON поле сущности хранится сериализованный вид модели, который тупо отдаётся дальше. Никаких динамических атрибутов, никакой логики.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Вы ничего не написали про поиск, и странно, что никто про это не спросил. А было бы интересно, как он реализован?
    • 0
      Про поиск вот в комментарии.

      Не только поиск пропустили. Расскажем ещё.
  • 0
    Медиа контент это так же аудио и видео. Работу по конвертации ролика в разное качество лучше возложить на профессиональную видео-платформу.


    А почему ffmpeg/avconv не хватило?
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Именно.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Да, готовимся к этому.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Никак не настраиваем. Теперь посмотрим.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Спасибо, практичная информация.

    Не смотрели на open gov проект?
    alphagov.github.io
    github.com/alphagov

    Мне кажется у них тоже интересный опыт — развернуть инфраструктуру для системы публикации британского правительства.
  • 0
    Спасибо, очень интересно! Вспоминаю как мы перезапускали actualidad.rt.com/ переводили с Perl на Python (Pylons+Postgres).
  • 0
    Второй раз сейчас занимаюсь перезапуском.
    Хотелось бы почитать такой же отчет с с точки зрения выпускающих редакторов, главредов, а не только технарей.
  • 0
    >Исправление опечаток на сайте выходит с задержкой меньше минуты.
    А почему не сделать, чтобы материал удаляется из кэша, только когда он изменяется? Тогда задержек вообще не будет
    • 0
      Во-первых правильнее будет тогда уж делать не удаление из кэша, а обновление.

      Во-вторых реализация такой системы немного сложнее. Необходимо формировать очередь на события обновления материалов. И в фоне уже делать запросы на обновление. Тут надо смотреть, на чьей стороне реализован кэш, в каком формате данные, как формируется ключ.

      В-третьих есть риск слишком частого обновления страницы (например главной). Тогда надо либо делать таймауты, либо разбивать страницу на SSI инклуды, либо… В общем некая логика, которая забоится о достойном соотношении «отдать из кэша/заново сформировать контент».

      Итого имеем: простая система с временем обновления до минуты; сложная система, с обновлением за секунды. Так как минуты – допустимое значение даже для сверх срочных новостей, то рациональным решением является выбор первого варианта.
  • 0
    11 человек на фото — достаточно много.
    В чем прикол? Количество человек больше чем количество шаблонов вывода lenta.ru
  • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Собираемся написать об пост ошибках разного рода, которые жизнь попортили.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.