Раньше не писали. Возможностей ORM хватало с головой. Позже стало ещё проще – старались делать запросы попроще. Самой большой проблемой при смене базы данных была миграция сами данных. Вроде полно скриптов, которые должны облегчить жизнь, но на практике пришлось повозиться. Кроме того был момент: приостанавливать работу редакции или нет. Решили, что проще для всех, если мы на некоторое время остановим редакцию, нежели будем делать realtime репликацию-миграцию или доливать изменения.
Сейчас ситуация хуже. Из-за активного использования в PostgreSQL таких структур данных, как array, hstore, json, приходится писать raw sql, в основном для выражений where. Одна из проблем ActiveRecord. Добавим до кучи жёсткую привязку всегда иметь поле id primary key – с любой нестандартной схемой начинаются танцы. Посматривали на Sequel, но пока не решились.
Так может подробно и опишите, как упростить локальное развертывание nginx? Например неплохо бы, чтобы у нас был доступен некий app.local который частично повторяет логику production конфигурации.
А тут просто. При разработке на локальной машине, ребята запускают веб приложения через Pow. Соответственно nginx с его настройками локально нет. В production стараемся делать это средствами nginx.
Да. И с помощью nginx можно перестраховаться, если после релода приложение валится. В ситуации с одним сервером это хорошее решение. А если кластер, то лучше балансировать уровнем выше, конечно.
В Ленте – нет. Зачем? Если редактор захочет навредить, есть более элегантные способы. Например был прецедент, когда редактор навставлял безобидных ссылок на свой сайт в начале своих заметок.
А можно ещё написать слово-орган в заголовке, и изданию выдадут предупреждение!
В том контексте EM была как раз кстати. Демон большую часть времени ничего не делал. Ждал когда в очереди появится заявка, скачивал файл. Заявок было немного, а время реакции внешних ресурсов – велико.
Когда практика большиства, в вопросе использования потоков, будет распространена – мы тоже до этого дойдём в основных задачах.
Для реализации поска в Ленте использовался внутренний поиск Рамблера, который в свою очередь организован на Sphinx. Раз в N минут к нам приходит запрос от поисковика за обновленными записями для индексации. Чтобы найти материал мы через HTTP обращаемся к поисковику и получаем JSON.
В Ведомостях сейчас стоит Sphinx, в разрабатываемой версии будет использоваться ElasticSearch. Отправка данных на индексацию будет реализована похожим способом.
Адрес страницы
URL каждой заметки делается человеко понятным. В Ленте он составляется как слаг типа материала, дата, слаг данной заметки (пишется руками редактором). Итого получается нечто /news/2012/12/22/foobar/. Каждый элемент адреса редактор может скорректировать.
В новой версии Ведомостей для составления адреса используются слаг первой рубрики, слаг типа материала, дата, транслитерация заголовка. Как пример: /finance/news/2012/12/22/foo-bar/.
Если заметка будет опубликована, адрес страницы будет зафиксирован. Есть возможность создать ассоцииованный адрес, и сделать его основным. Это используется, если надо изменить рубрику, дату, или заголовок.
Релевантные материалы
Если блок связанных материалов (ссылки по теме) формируется строго руками. То в блоках «Читайте так же» материалы подбираются очень просто: самые свежие по заданному срезу. Например самые свежие в той же рубрике и теге, что и первый рубрика и тег материала. Никакие интеллектуальные системы здесь не нужны – это лишнее.
В прошлой было несколько статусов, но без state machine.
Сейчас сделали ещё проще, как вы и сказали, черновик/опубликовано.
Все дополнительные статусы нужны только для организации редакционного процесса. Как то «не выдана», «выдана редактору», «завершена», «вычитана», «окартинено»… Соответственно есть некоторый набор списков заметок, сгруппированных по определенным признакам, в том числе подобным состояниям. В зависимости от сценария, заметки перетекают из одного потока в другой.
В Ленте на фронте вообще только MongoDB была со своим драйвером, в CMS sql база.
В Ведомостях модели одной и той же сущности разнятся в функциональном плане. Они вообще ориентируются на использование разных атрибутов. В JSON поле сущности хранится сериализованный вид модели, который тупо отдаётся дальше. Никаких динамических атрибутов, никакой логики.
Сейчас ситуация хуже. Из-за активного использования в PostgreSQL таких структур данных, как array, hstore, json, приходится писать raw sql, в основном для выражений
where. Одна из проблем ActiveRecord. Добавим до кучи жёсткую привязку всегда иметь полеid primary key– с любой нестандартной схемой начинаются танцы. Посматривали на Sequel, но пока не решились.А можно ещё написать слово-орган в заголовке, и изданию выдадут предупреждение!
Медленнее стало субъективно. Они ж ничего не замеряли! Там не всё отлажено. Например скачем между LXC vs Docker. Финализируем – расскажем.
Не только поиск пропустили. Расскажем ещё.
Но теперь в Ведомостях, сразу начали без него. Нам немного надо, но с какой-то бизнес логикой. Поэтому велосипед.
Про simple_form сейчас kSavelyev ответит.
Когда практика большиства, в вопросе использования потоков, будет распространена – мы тоже до этого дойдём в основных задачах.
Для реализации поска в Ленте использовался внутренний поиск Рамблера, который в свою очередь организован на Sphinx. Раз в N минут к нам приходит запрос от поисковика за обновленными записями для индексации. Чтобы найти материал мы через HTTP обращаемся к поисковику и получаем JSON.
В Ведомостях сейчас стоит Sphinx, в разрабатываемой версии будет использоваться ElasticSearch. Отправка данных на индексацию будет реализована похожим способом.
Адрес страницы
URL каждой заметки делается человеко понятным. В Ленте он составляется как слаг типа материала, дата, слаг данной заметки (пишется руками редактором). Итого получается нечто
/news/2012/12/22/foobar/. Каждый элемент адреса редактор может скорректировать.В новой версии Ведомостей для составления адреса используются слаг первой рубрики, слаг типа материала, дата, транслитерация заголовка. Как пример:
/finance/news/2012/12/22/foo-bar/.Если заметка будет опубликована, адрес страницы будет зафиксирован. Есть возможность создать ассоцииованный адрес, и сделать его основным. Это используется, если надо изменить рубрику, дату, или заголовок.
Релевантные материалы
Если блок связанных материалов (ссылки по теме) формируется строго руками. То в блоках «Читайте так же» материалы подбираются очень просто: самые свежие по заданному срезу. Например самые свежие в той же рубрике и теге, что и первый рубрика и тег материала. Никакие интеллектуальные системы здесь не нужны – это лишнее.
Нет задачи обходить стороной нестандартные решения. Практиковаться можно на мелких проектах.
Сейчас сделали ещё проще, как вы и сказали, черновик/опубликовано.
Все дополнительные статусы нужны только для организации редакционного процесса. Как то «не выдана», «выдана редактору», «завершена», «вычитана», «окартинено»… Соответственно есть некоторый набор списков заметок, сгруппированных по определенным признакам, в том числе подобным состояниям. В зависимости от сценария, заметки перетекают из одного потока в другой.
В Ленте на фронте вообще только MongoDB была со своим драйвером, в CMS sql база.
В Ведомостях модели одной и той же сущности разнятся в функциональном плане. Они вообще ориентируются на использование разных атрибутов. В JSON поле сущности хранится сериализованный вид модели, который тупо отдаётся дальше. Никаких динамических атрибутов, никакой логики.