TJ Ilya Chekalsky
5 162

Основа 2.0

Changelog и технический post-mortem перезапуска.

В закладки
Аудио

На самом деле написать чейнджлог у меня не выйдет. После пары месяцев записывания того, что мы поменяли во второй версии Основы, я понял, что проще будет записать то, что осталось как раньше. Вот так выглядит сравнение двух версий на Github — 3109 изменённых файлов, 300 000 изменённых строк (но часть из них, конечно, технические).

Основа — это платформа, на которой сейчас работают сайты Комитета: vc.ru, DTF и TJ. Мы начали писать её два года назад, в ноябре 2016 года. Тогда каждый из трёх сайтов имел собственный движок. Баги в каждом нужно было исправлять отдельно, фичи реализовывать по несколько раз. Очевидно, долго так продолжаться не могло.

В 2017 году начался переезд всех проектов на Основу — сначала DTF, затем TJ и потом vc.ru. Так мы добрались до начала 2018 года — и у нас накопилось много вещей, которые хотелось бы изменить. Первая версия движка не предусматривала никаких разделов, кроме заранее захардкоженных — для каждого зачастую была какая-то своя логика (чего стоила Аляска, не попадающая в ленты). Параллельно на vc.ru стало появляться всё больше страниц компаний, которые требовали создание новой сущности — с возможностью вселяться в неё сотрудникам.

В этот момент неосторожное предложение технического отдела «так давайте сделаем одной сущностью пользователей, компании и подсайты» дало рождение новой версии вашего любимого сайта. Вместе с этим вакансии, сделанные как MVP на коленке за месяц, стали одной сущностью вместе со статьями. Аналогично поступили и со статичными страницами вроде правил сайта — раньше это было просто html-файлы. Теперь их можно верстать в редакторе силами любого сотрудника, необязательно привлекать для этого разработчиков.

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

Часть задач, вынесенных на рефакторинг

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

Отвлечёмся на секунду и я расскажу, что такое Подсайт и Контент. Это две основополагающие сущности всего сайта. Подсайт — это всё, что генерирует или содержит Контент. То есть с точки зрения базы данных никакой разницы между пользователем, компанией или подсайтом нет. Каждый из них может быть как автором контента, так и его владельцем.

Например, когда я пишу этот пост, в поле creator_id будет проставлен мой id, а в поле owner_id — id подсайта «TJ», в который я и пишу. Но я могу изменить creator_id на id «TJ» и тогда «TJ» напишет сам в себя — так тоже можно. Или можно взять компанию и написать от её имени в любой подсайт — тогда она будет отображаться в качестве автора. Как вы уже догадались, это значит, что технически каждый пользователь может писать сам в себя — так мы получим личные блоги.

Если я сотрудник Комитета и хочу от имени компании написать пост на vc.ru мне нужно в неё вселиться. Мы разрабатывали это по аналогии с фейсбуком, где можно комментировать или лайкать от имени своих страниц. Теперь у нас можно так же. Поэтому нам пришлось отделить подсайты (пользователей, компании) от их логинов, и каждый логин может вселяться в неограниченное количество подсайтов, которые ему подвластны. Ширяев, например, может вселиться в подсайт Сломалось и ставить вам лайки по всему TJ. Для этого ему не придётся как-то отдельно логиниться, он просто переключит аватарку в шапке.

Когда мы реализовывали вселение, мы столкнулись с такой проблемой — когда пользователь покупает подписку на TJ, то подписка должна привязываться к логину или к подсайту?

Если привязать к подсайту, то когда человек вселится в аккаунт своей компании, ему придётся покупать подписку ещё раз, чтобы от её имени написать комментарий. Довольно спорная механика. Решили привязать к логину, посмотрим, что из этого выйдет.

Отдельной проблемой на Основе 1.0 для нас были комментарии. Вообще, начать рассказывать надо с того, как у нас работало кэширование. А работало оно так: все страницы сайта были закэшированы на уровне nginx, а персональные данные вставлялись с помощью ajax-запросов. Это позволяло держать любую нагрузку (если мы где-то не косячили) — пользователю моментально показывалась страница из супербыстрого кэша, а потом догружалась аватарка в шапке, оценки постов и комментарии. Всё было хорошо, пока мы не за***лись инвалидировать этот кэш и писать бесконечные запросы, чтобы отобразить хоть сколько-нибудь динамичную фигню — в противном случае она могла закэшироваться на час.

Ну и не проходило недели, чтобы кто-нибудь не жаловался на медленно загружающиеся комментарии. А когда происходило что-то вроде учёбы в Англии, наступал просто конец — и стало понятно, что никакие отговорки про несовершенные браузеры нам не помогут — нужно было грузить комменты с бэка вместе с телом страницы, а это значило распрощаться с нашим прекрасным кэшированием (которое мы хотели даже заопенсорсить, но не успели).

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

В общем, зарелизили мы вторую версию Основы на DTF только в конце мая. Вскоре после этого vc.ru начал задыхаться без функциональности компаний — пришлось менять привычный уклад и перезапускать во вторую очередь его. Это дало такой буст, что следующие пару месяцев мы релизили множество новых фич, отлаживая механизмы работы ленты и всяких настроек, с которыми вот и приехали на TJ.

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

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

Спасибо ребятам из нашей великолепной команды разработки:

Паша, Мурод, Гоша, Абдужаббор (бэкенд)

Петя, Артём, Мика (фронтенд)

Слава, Кирилл, Макс (мобильные приложения)

Валера и Женя (спецпроекты)

Александр, Лёша и Костя (дизайн)

Влад, Филипп, Денис и Орзик (продукт и менеджмент)

{ "author_name": "Ilya Chekalsky", "author_type": "editor", "tags": [], "comments": 153, "likes": 158, "favorites": 40, "is_advertisement": false, "subsite_label": "team", "id": 81131, "is_wide": false, "is_ugc": false, "date": "Thu, 06 Dec 2018 12:49:53 +0300" }
{ "id": 81131, "author_id": 1, "diff_limit": 1000, "urls": {"diff":"\/comments\/81131\/get","add":"\/comments\/81131\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/81131"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 214350 }

153 комментария 153 комм.

Популярные

По порядку

Написать комментарий...
36

Давайте все-таки засунем vc и d*f в подсайты tjournal, чтобы восстановить справедливость во имя всего

Ответить
7

НИНАДА БЛЯДЬ

Ответить
6

а что на этот счёт думает издательский дом КОМЕНДАНТ?

Ответить
28

каждый пользователь может писать сам в себя

Ну физически это было возможно и без вашей основы

Ответить
0

Это как?

Ответить
3

Все перечеркнул одной шутейкой!

Ответить
0

Я все порчу. Я знаю.

Ответить
1

хороша шутеечка

Ответить
11

А могли просто поставить Вордпресс и не париться.

Ответить
3

И не говори

Ответить
11

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

Ответить
9

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

Ответить
25

Решили побыстрому на пивко срубить донатов

Ответить
4

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

Ответить
0

Пофиксили.

Ответить
1

Теперь пофиксили

Ответить
0

Да, уже лайкнул

Ответить
0

А у вас там поэтому универсально написано "купить для пользователя X"? Скоро холопам из бесплатных подсайтов можно будет подписку в подарок брать?

Ответить
6

Круто! Спасибо за пост!

Ответить
3

Илья, есть ли возможность по ссылке из прямого эфира идти в нормальные коменты, а не в одну ветку?

Условно то, что есть сейчас это потому что иначе упадет сервер, или прихоть Ширяева (бла бла про старые компы типа пихто, которые еле ос загружают)?

И еще, почему вместо прежнего прекрасного цитирования сделали вот такое (в чем причина)?

Ответить
2

Это техническое ограничение — и Ширяев лоббирует как раз нахождение способа его обойти.

Вкратце выходит так: мы имеем id коммента и должны отрендерить страницу с комментариями так, чтобы этот коммент был на этой странице (а его может не быть, если он в глубине веток) и мы могли к нему проскроллить. Мы попробуем найти способ рендерить комменты вокруг указанного, но это не так просто.

Проблема с нагрузкой и на серверной стороне (1000 комментов занимают уйму памяти в текущей архитектуре) и на клиентской, где браузерам тяжело рендерить столько комментов (а там и аватарки и кому ответил и три точки и оценки, в общем, куча слоёв).

Потому что дизайн.

Ответить
0

Илья, а комменты выбираются разве из базы не все скопом?
Или у комментов есть поле "уровень вложенности" и дальше какого уровня они не выбираются из базы?

Ответить
1

1) да, селектим все, но только в виде (id, parent_id)
2) бегаем по ним и строим обрезанное дерево
3) рендерим то что попало в дерево

Ответить
0

Ну так если есть айди нужного коммента, то можно обрезать все другое, кроме ветки с нужным id

Ответить
0

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

Ответить
0

Да, но я имел ввиду делать так:

Когда выбираются все комменты:
1. Выбираются все комменты
2. Строится дерево
3. Обрезаются длинные или глубокие ветки
4. Рендерится оставшееся.

Когда запрашивают конкретный коммент
1. Выбираются все комменты
2. Строится дерево
3. Находим всю ветку с конкретным комментом
3. Обрезаются длинные или глубокие ветки, кроме ветки с выбранным комментом. Возможно, для сокращения общего числа оставшихся комментов, ужесточать критерии обрезки для других веток
4. Рендерится оставшееся.

Ответить
0

Когда запрашивают конкретный коммент

Пытаемся, но поди напиши эту SQL-ку, да чтоб еще быстро работала

Ответить
0

Пока как-то с трудом представляю в чем сложности.
Можно как-нибудь пересечься, подумать вместе над этим)

Ответить
9

ееее бухать и пиздеть за архитектуру

Ответить
0

рахитектуру*

Ответить
0

ох уж эти ваши шуточки про пхп

Ответить
0

Да, он говорит про такие ссылки: https://tjournal.ru/stories/70206-kak-ya-napisal-bota-kommentatora-dlya-tj-i-ne-umer?comment=1580737

Чтобы по ним показывались все комменты и скроллилось к нужному

Ответить
0

А вообще можно попробовать добавить помимо parent_id поле с materialized path.

Так можно будет дергать только одну ветку из базы без всего остального

Ответить
0

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

Ответить
0

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

Ответить
1

Не, чтобы дёрнуть одну ветку не надо как раз все доставать. Но чтобы сделать как просят придётся начать это делать.

Ответить
1

Я бы хотел, чтобы все коменты показывались сразу при переходе. Когда я у Ширяева спросил, он что-то там про слабые компы ответил. Но как-то хуево имея нормальный комп и телефон подстраиваться под 15летней давности железо.

Ответить
1

У тебя открывалась Учёба в Англии без проблем?

Ответить
0

Если не считать некоторых затрат по времени, которые несущественны если открывать в новом окне (и продолжать читать текущий пост), то да.

Ответить
0

Уверяю, тормозила она (я про старую версию) далеко не на компах 15-летней давности.

Ответить
0

Но конечно мы на это пошли ещё и для серверной оптимизации.

Ответить
0

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

Ответить
0

Я не думаю, что мы будем добавлять такую кнопку, потому что 10 человек с расширением не так страшно как 100 с кнопкой.
Если расширение начнёт забивать сайт запросами, то там уже будем думать.

Ответить
0

Мы попробуем найти способ рендерить комменты вокруг указанного, но это не так просто.

Nested set не рассматривали? Я так понимаю, что с ним можно и комменты на текущем уровне дёрнуть, и родителей, и детей?

Ответить
0

Вокруг — имеются ввиду соседние треды, в рамках текущего треда нет проблемы рендерить, проблема чтобы сделать страницу с комментами так, чтобы выьранный коммент гарантированно на ней был и чтобы это не было напряжно для сервера

Ответить
0

В текущий момент обычно работает клик на комент -> показать все -> кликнуть еще раз.

А если все коменты сразу разворачивать (скажем автоматически) на сколько нагрузка на сервер увеличится"

Ответить
0

Они не поместятся в память в текущем виде даже. Если это в разных запросах делать, то там наверное есть где-то предел, но пока не сталкивались и специально не тестили.

Ответить
0

nested set сложно, со своей стороны предложил бы closure table

Ответить
1

А для моб приложения планируется горизонтальный формат? С него было бы удобнее читать лонгриды.

Ответить
11

Лонгриды читать горизонтально? Эээ..

Ответить
17

Вайдриды

Ответить
3

Для Android нет планов

Ответить
0

Жаль, мое следующее устройство будет сугубо горизонтальным. А темная тема не планируется случайно? Я сейчас только из-за ее отсутствия не могу пользоваться.

Ответить
0

Что за устройство? Если я не ошибаюсь, с рутом можно игнорировать указания разработчиков в манифестах и крутить ориентацию как хочешь, но очень часто будут траблы с корректностью отображения.

Ответить
0

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

Ответить
0

Cosmo Communicator

Но зачем?

Ответить
0

Эх, зря спросили... Я на своей волне, меня уже достаточно минусовали тут, за мое мнение об этом устройстве (и вообще за то, что я телефон себе раз в 5 лет покупаю). Нравятся мне клавиатурные устройства, нравятся мне стилусы, но когда есть выбор между стилусом и клавиатурой - я выбираю клавиатуру. Мой Note 3 пора отправить на покой, старичок отслужил мне верой и правдой много лет, и до сих пор служит благодаря прошивкам от сообщества, на Cosmo Communicator еще и поддержка Linux есть, а я такое люблю. Плюс - разборность, емкая батарея, все что мне надо! Никаких идиотских двойных камер, никаких скрепок для вынимания SIM-карты, никаких несъемных и залитых на клей крышек батареи, никаких украденных пикселей в углах экрана и идиотских челок. По-настоящему рабочее и удобное устройство, как раз тот самый бизнес-сегмент, который мне и нужен.

Ответить
0

А что минусовать? Я понимаю любовь к клавиатурным устройствам, но всё-таки это довольно сомнительное решение в том плане, что он довольно здоровый, но при этом недостаточно большой, чтобы было удобно работать за клавиатурой – там маленькие кнопки. Учитывая, что клавиатура мелкая, то плюс от установки линукса как-то сразу уходит на нет. Может вариант из телефона + нетбука будет удобнее? Телефон, чтобы звонить, слушать, например, музыку и листать соц.сеточки, а условный нетбук как раз для нормальной работы за клавиатурой.
+ у меня еще есть подозрение, что если вдруг коммуникатор навернётся, то придётся искать специфический ремонт или играть по гарантии. Телефон на андроиде или айфоне тебе в любой подворотне починят, а тут шайтан-машина непонятного вида.

Ответить
1

Мне лично как-то безразлично на гарантию, если устройство сломается - я просто больше его не куплю (причем, программный ремонт я могу вполне самостоятельно осилить, аппаратный мелкий тоже, благо руки прямые и голова на месте). Я уже как-то купил iPhone 4, так он связь терял, после того, как ты заехал в туннель (а я, к сожалению, часто за рулем разговариваю по телефону), а потом, когда выезжал, так и не находил, хотя показывал все "палочки" приема сети. Так и не смогли мне это починить. Да и вообще, по сравнению с моим коммуникатором на WM он очень часто терял связь, а это для меня крайне критично. Насчет довольно здорового - поищите, как выглядит чехол 10000mAh на телефон, вот - у меня такой, так что меня "здоровость" не пугает, даже радует, не потеряется нигде, и не забудешь. Сейчас со мной ездет MacBook Air, удобная шутка, но мечта устроства "все в одном" покоя не дает.

Ответить
0

Напишите что ли заметку потом сюда об этом девайсе. Сомневаюсь, что на всю Россию будет хотя бы владельцев 10 и что кто-то из них что-то напишет.

Ответить
0

Кстати зачем нужен стилус в 2018 году? Я понимаю там в 2005, когда на дворе был Windows Mobile с его мелким интерфейсом, но сейчас-то зачем, когда интерфейс около-всех приложений давно адаптирован под палец? Заметки писать? Камон, тогда уж лучше клавиатурник найти, а не страдать с распознавалками рукописи.

Ответить
0

А я вот такой извращенец, у меня здоровенный экран аж 5", а в прошивке так выставлено разрешение, чтобы все мелкое было. Меня мало кто поймет, но мне так удобнее, потому что на экране сразу помещается много информации, как во времена WM. Я ненавижу пустое место, а еще стилусом работать как-то эстетически приятнее, человеку нужно орудие, я не обезьяна, чтобы пальцем тыкать.

Ответить
0

5 дюймов нынче копейки :)
У меня на BlackBerry, где половина экрана отнята клавиатурой, 4.5'. Многие люди бояться брать именно из-за "маленького" экрана.

Ответить
0

Я не против добавить, но дизайна нет

Ответить
0

Плюсанул за горизонтальный формат, но не понимаю, как так можно читать лонгриды. Если только на планшетах, и то хз

Ответить
0

Не, именно с мобилы. Так глаза меньше устают, удобнее жи

Ответить
5

Знаешь толк в извращениях

Ответить
–3

И спасибо за баг, позволяющий читать все комменты без подписки!

Ответить

Комментарий удален

0

Ну если не баг, тогда круто все равно

Ответить
5

Ага. Баг.

Ответить
1

С приложения

Ответить
0

Ребята, вам нужно нагрузочное тестирование!

Ответить
7

Готов на сервер присесть, жирдяй?!

Ответить
0

Даже уронить могу!
(со стола)

Ответить
1

если что, я в этом шарю, могу помочь

Ответить
0

всегда готов натравить своих павуков

Ответить
1

вообще очень классный движок получился, много фитч

Ответить
1

Спасибо за работу!

Ответить
0

пока мы не за***лись инвалидировать этот кэш

почему бы и не заебаться?

нужно было грузить комменты с бэка вместе с телом страницы, а это значило распрощаться с нашим прекрасным кэшированием

Varnish ESI может частично решить эту проблему

Ответить
3

Если интересно, я вот не так давно рассказывал про нашу систему кэширования (англ.) и у меня остались слайды

https://docs.google.com/presentation/d/1Zjsg4g9obOnMaF4HEoqtWS9xjG5N7_uycEqK1v3asTs/edit?usp=sharing

Ответить
15

ВОТ И ОТВЕТ

Our own modular framework called Osnova («Podstawa»)

Ответить
5

Польский 💖

Ответить
0

Потому что при малейших изменениях иногда надо половину сайта проинвалидировать. У нас был механизм который просто таймстемп последней инвалидации писал в мемкеш, а nginx с модулем на lua проверял и либо грузил из кэша, либо шёл на бэкенд.

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

Ну и каждый дополнительный уровень приносит дополнительные баги и сложность.

Ответить
0

А как пришли к необходимости кеша всей страницы? Это, видимо, сразу и был первый кэш, который применили? Без кэша уже совсем не работало? Рассматривали ли варики кэшить данные, а не страницы?

Ответить
0

До этого всё было в мемкеше на уровне PHP, но страницы намного проще кэшировать, так и пришли. Выше оставил ссылку на слайды моего выступления про наш страничный кэш.

Ответить
0

Varnish умеет делать все то же самое что и ваша связка(nginx+lua+memcache), достаточно гибко на уровне компилируемых конфигураций + ESI. Бонусом фишки типа Varnish Broadcaster для DIY CDN

Ответить
0

И да, все это на уровне community версии. Энтерпрайз аналог, как и у NGINX (Varnish+) есть, но стоит сравнимых денег(больших)

Ответить
0

Ну это недавно появилось в комьюнити, когда мы пилили своё на lua, его ещё не было.

Ответить
0

Ну Broadcaster сравнительно недавно. А вообще очень гибкий достаточно динамичный кэш данных/страниц удобно делать уже в версии 4.0(2014 год)

Ответить
0

Мне всё равно кажется, что у нас слишком много динамических блоков на каждой странице для ESI

Ответить
0

Ну мне тоже кажется что статичный(такой как текст поста) результат удобней и правильней кэшировать полноценно и намертво. А данные разной динамичности лучше выделять в отдельные эндпоинты и сервисы.

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

Ответить
0

Отдельно выделенного QA у вас нет?

Ответить
1

Тестированием занимается Орзик

Ответить
17

Тестированием занимается DTF.

Ответить
7

*Тестированием занимаются юзеры

Ответить
4

Весь отдел на мне

Ответить
1

и бета-чат в телеграме

Ответить
0

чего стоила Аляска, не попадающая в ленты

if (post.CategoryName != "alaska")
posts.Add(post);

Ответить
2

и if (site == 'tj') еще!

Ответить
0

Поздравляю с первым комментом, кстати

Ответить
1

спс +) не удержался +)

Ответить
0

Наконец технический топик, грасиас. Осталось развести под постом какой-нить холивар и будет как в старые добрые.

нужно было грузить комменты с бэка вместе с телом страницы

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

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

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

Ответить
1

Всего лишь за год образумились

Ну осознали ошибку мы быстрее, просто такой большой кусок не так просто переписать быстро.

Вижу излишнее желание сделать красивую абстракцию. По мне так обрекаете себя на излишние валидации и баги

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

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

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

Ответить
0

тут получилось идеально

проверим через год :)

Ответить
0

збс, вы в двоем все пилите?

Ответить
1

Там внизу же целый список

Ответить
0

Его нужно подгружать по клику с допзапросом? ))

Ответить
0

ослеп))

Паша, Мурод, Гоша, Абдужаббор (бэкенд)

Петя, Артём, Мика (фронтенд)

Слава, Кирилл, Макс (мобильные приложения)

Валера и Женя (спецпроекты)

Александр, Лёша и Костя (дизайн)

Влад, Филипп, Денис и Орзик (продукт и менеджмент)

Ответить
0

3к файлов, охуеть.
А код-ревью перед мержами не делаете что ли?

Ответить
1

Делаем, но когда рефакторишь какую-нибудь оплату и там изменений на 2000 строк, то конечно это PR сложно качественно отревьюить. В течение рефакторинга накапливается много таких кусков. А так каждый пул реквест должен получить approve перед мерджем в мастер.

Ответить
0

А што у вас с гендерным и расовым разнообразием в команде м?

Ответить
0

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

Ответить
2

А как обстоят дела с ЛГБТ?

Ответить
0

Я не был серьёзен, если что. Да и ситуация с девушками понятная для России и соседей.

Ответить
0

Под капотом «самописный» движок на PHP?

Ответить
0

Да

Ответить
0

Почему был выбран PHP, а не Python, к примеру? Наследие первой версии движка?

Ответить
4

И да и нет. Разработчики в команде пишут на PHP в основном, это обусловлено предыдущим движком, ну и у нас нет никаких проблем с PHP, если честно.

Ответить
0

Перейдите уже наконец на Go.

Ответить
0

Мы используем и Go, но писать на нём Основу не только нерентабельно, но ещё и очень сложно и долго.

Ответить
0

Без использования framework типа Symfony/Lavarel/Yii2? Просто интересно как собран проект.
Умерший клон хабр-движка Livestreet помер из-за не использования framework. Точнее они пили свой велик с квадратными колесами, половиной руля и двумя сиденьями...

Ответить
0

Мы используем готовые компоненты там, где можно, в том числе и из Symfony.

Есть версия, что Livestreet помер не из-за движка, а из-за отсутствия спроса и мотивации.

Ответить
0

Сейчас с composer и PSR это норма строить свое с использованием готовых кирпичиков. Это радует и экономит время и нервы. :)

Если не секрет, то какие компоненты из Symfony используете для миграций, ORM , debug?
Что используете для поиска Sphinx, Elastic?

Ответить
1

Миграции на phinx
Поиск на elasticsearch

Ответить
0

И что с количеством комментариев в приложении под IOS? Я написал явно больше 34х.

Ответить
0

Баг, не учитываются комменты в платных подсайтах.

Ответить
0

Чинить конечно же не планируете?)

Что интересно, когда заходишь в профиль, на доли секунды показывается реальное количество (наверное, реальное) около 600.

Ответить
1

Да не, уже в тестировании фикс.

Ответить
0

В моем профиле тоже как-то странно отображается количество комментариев в разлогиненном виде. Пишет, что у меня 17 комментариев, хотя ни разу в бесплатных подсайтах не писал, а при переходе ошибка 403.

Ответить
0

А API Основы2 можно посмотреть или пока не готово?

Ответить
0

Денис недавно писал пост с приглашением в закрытый подсайт по апи, посмотри

Ответить
0

Не буду врать - не профессионально сделано, сорри за прямоту

Ответить
0

Кстати могу писать только в приложении, на сайте ничего не работает

Ответить
0

Да не проблема, а что именно не так?

Ответить
0

У вас абстракция юзера потекла, знатно так.

Ответить
0

А можно подробнее?

Ответить
0

Если я правильно все понял, подсайт и юзер у вас находятся в одной табличке.

Ответить
0

Все верно, но данные логина (пароль, соцсети) в отдельной и связь на вселение может быть и с подсайтом и с юзером

Ответить
0

Ну собственно в этом и является проблема протекающей абстракции и не пытаться сделать из юзера раздел на каком то сайте. Но с этим вам конечно же жить. Я бы делал иначе :)

Ответить
0

Просто попытка как можно изящнее решить ситуацию, когда есть три сущности, которые могут выступать автором контента или комментариев (юзер, компания, подсайт) и писать этот контент в друг друга и самих себя

Ответить
0

Интересно, приведет ли это три сайта к общей платформе, в итоге: к общему кросс-логину (либо вообще одному аккаунту), единому центру уведомлений, к общей системе оплаты и даже одному домену?

Ответить
0

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "cndo", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "cndo", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "i", "ps": "cndo", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "i", "ps": "cndo", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "cndo", "p2": "ezfk" } } }, { "id": 6, "disable": true, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "clmf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byswn", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "cndo", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "cndo", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "cndo", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "cndo", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223677-0", "render_to": "inpage_VI-223677-0-130073047", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=cndo&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudv", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "ccydt", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "cndo", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "cndo", "p2": "fzvc" } } } ]
Не пропустите самое важное,
что происходит в интернете
Подписаться на push-уведомления